>
>However, it seems to me the best solution for making views in this example is to make a view containing 2 tables: Customer Product, and Product. We'll return all the fields of Customer Product, and just the Name & Description from the Product table.

That's what I'd do. The other way is way to complicated.

>
>But which class should have the method that calls this view? Customer, Customer Product, or Product? If I ever made a change to either the Product

I'd put it in either the Customer or Customer Product object. Probably in the CustomerProduct object since that's closer to its function than in Customer.


>table, or Customer Product table, how do I know which views are affected? >Doesn't this violate the black box idea of keeping each class independent from >one another?

Not really. Views aren't classes, so the same rules of OO don't apply. As far as keeping track of the views affected, you might want to include that information in any DB design tool you might use. I've been playing with a few different ways of keeping track of my views and the tables they relate to. For example, in Visio I've got a layout that shows the relations between tables. In another layer I add an attaching line showing my views and the relationships between then and the underlying tables. My diagrams tend to be pretty simplistic - I normally don't include all the fields in each table in the diagram. Things get way to messy that way. Usually just the table name, and sometimes the primary key and any foreign key names I'm using.

The other thing I've tried doing is coming up with some sort of standard way to handle my classes and which views are associated with each. I've got a book on UML that I haven't had a chance to read, so there might be a "standard" way to do something like this. My thought was to draw a box to the left of each class that listed each view used by it, putting the primary (or Initial Selected Alias in MM-speak) at the top and/or highlighted.

HTH