Tim,

The reason I created two business objects in these type cases was mainly due to time constraints I had when coding the application. I needed to get things done quickly and did not have the luxury to think things through. I started with the table based BO and realized later I needed more to populate my grids. When the idea came to mind and I saw that it worked well, I went with it. Remember though, that I have not duplicated the rules, defaults and main business logic from the table, I have just created another Entity object based on the view instead of the core table. But I agree with your statement below.

After thinking this through following my last reply in this thread, I wondered if I created the 'Main' business object off a view which contained all the foreign key reference values and used this as my one an only one BO for the underlying table, it could work. Since the generator does ask what is the underlying table for the view, I am thinking that this could work with the Generator.

I then tried this and got an error in the BO Generator. I think it was due to column values that got generated in the stored procedures. I believe with a little work this can be accomplished. In fact, now that my app is live (went live this past summer), I have a little more time to take a closer look at this.

I will say that I think changing this will show little or no increase in performance, but would reduce a few lines of code and code files.

Are you saying that you create Business objects based on a view and have made this work with one BO set of rules, defaults, etc.?? If you have let me know if you have done this with the BO Generator, or just updated the source files manually after using the Generator.

Anyway, thanks for your input. It certainly helps to hear different points of view from the community.

Happy Holidays!

>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