Hi Bob,

>What I have done is create two business objects for this situation. The first is based on the table (e.g. Orders) and is generated with the BO generator. It ends up with the 4 classes (Main class, Entity class, Rules class and defaults class) and with the data access class as well. This object does not contain the referenced columns (or description columns) for the foreign key colums (this is your dilemma).
>
>I then create a view in the database (e.g. vOrders) that contains all the columns in Orders as well as the joined description columns from all the foreign key reference table columns. This view now contains all the values I want to display in a grid on a form.
>
>Next, I use the BO generator to generate the necessary classes for use in my grid. However, all that is needed is to generate two classes. Those are the main class and the Entity class. There is no need for the Rules or Default classes and also no need to generate data access classes.

I am curious why you need the additional Business Object in additon to the view based Entity object. Did you find an advantage to putting all the code associated with the view (or seperate entity) in its own biz class? It looked like you used the overloads to specifiy the Entity object.


I have often wondered why Entities are so table based when in real life they are not. The tables get normalized and no longer represent an actual Entity. An Entity should be all the tables that are part of an Entity. It would be nice to have complex Entity that can manage all of its own relationships and rules as a single Entity.

How is your project going?
Tim