>
>It isn't wrong to have a DataAccess Object for each Business object if needed. In that case I would create a DataAccess Base class with the bulk of the retrieval code in it and then each DA can inherit from that with just the differences you need for that specific implementation. The crux of nTier is the use of MessagePassing between the layers. The UI does not do any data stuff it would ask your business object to do that. Your business object would then ask your DA to do the actual retrieval. The DA then after getting the data passes it back to the Biz Obj and the bizObj passes it back to the UI. With the DataAccess tier and a base class you keep your retrieval code clean and single minded. With your business objects in between the UI and DA they can do the enforcement of any rules as the requests go through them.
>Tim
On getting/loading the data from DA to UI (via BIZ) I have no problem using just one DA class; this fairly straight forward in my "framework". Where I have to have a separate DA tier class for each BIZ is when updating changes/additions back to the database. So I am glad you don't think it is such a bad thing.
Thank you.
"The creative process is nothing but a series of crises." Isaac Bashevis Singer
"My experience is that as soon as people are old enough to know better, they don't know anything at all." Oscar Wilde
"If a nation values anything more than freedom, it will lose its freedom; and the irony of it is that if it is comfort or money that it values more, it will lose that too." W.Somerset Maugham