Tim's answer was spot-on and good advice. I second his opinion.

~~Bonnie



>>
>>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.