I suspected that you would answer something along those lines. My point is why do you need a separate class to handle DB interactions with each DB object / table ? Tier based development is usually understood to contain the following very basic layers :
1. UI layer 2. Application/Biz Logic Layer. 3. DataLayer 4. DataStore. As such you should have a general Datalayer that handles all database interaction and passes ADO.NET objects to your Business logic layer. These objects are then converted after applying business rules to custom objects that are usable by the UI layer to display/add/modify the data. On Dec 18, 11:18 am, Sreenivas <[email protected]> wrote: > Generally,we write database interaction code in DB classes.. > eg:DBTask.cs > > On Dec 18, 12:10 am, Cerebrus <[email protected]> wrote: > > > > > What's a DB class ? > > > On Dec 17, 3:03 pm, Sreenivas <[email protected]> wrote: > > > > Hi, > > > I have 3 classes namely , > > > 1)Task > > > 2)Customer > > > 3)Project > > > > and their DB classes are > > > 1)DbTask > > > 2)DbCustomer > > > 3)DbProject > > > respectively.Is it a good idea to interact Business logic classes > > > (Task ,Customer,Project) with Db > > > classes?? > > > I heard creating DAO for .net is old fashioned one , > > > (http://social.msdn.microsoft.com/forums/en-US/adodotnetdataproviders/ > > > thread/7d30fbe3-b06d-48b9-a2c1-125acd608445/) > > > is it true? > > > Thanks in advance..- Hide quoted text - > > - Show quoted text -
