Hi Christof!

I'm sorry, I have to disagree with you a little bit on your explanation of Data Access layer vs Database Access. I believe that the database-specific class should be a parent class, exposing all it's method calls via the set of IDb* interfaces. This lives in it's own project. You can have one for each back-end database you support, but they would all be exactly the same as far as the methods that are exposed (and the projects would all have the same namespaces as well ... probably would need to have the extraneous projects developed under different solutions and only use one of them in normal development, such as the one that talks to SQL).

Each of your DataAccess classes then sub-class from this class and subsequently neither know nor care what the back-end database is.

When you then distribute your app to your customers, you substitute the appropriate DLL for the base class depending on which backend database your customer uses.


See my post at Message #1369681 that describes the class structure and methods for both the parent class (SQL-specific in this case) and subsequent sub-classes. My only caveat is that we talk to the database only through Stored Procs, so we can only support backend databases that utilize Stored Procs, but I don't see anything wrong with that requirement. <g>

Does this make sense to you?

~~Bonnie




>Hi Dmitry,
>
>>In the 3-tier application you have a bunch of BIZ objects, for different entities. That is clear. Is it correct to assume that there should be only one DA object that all BIZ objects use to update the database?
>
>Depends on what the DA means to you. Often you have the following layers (UI aside):
>
>Business object: Contains all business logic on an abstracted level. There's absolutely no database specific dependency in this layer including any of the SQL data types.
>
>- Data access layer: Is specific to the BO and the backend. The DAL contains all the data related parts. It handles the translation between .NET types and SQL types, transforms object dependencies into related entities, etc. There's one DAL object for every BO and every supported back end. The DAL does not talk directly with the database
>
>- Database access: handles the actual access to the database. This layer manages connections, permissions, transactions, sends SQL commands, etc. There's only one Database Access object for each back end that all DAL objects talk to. Well, usually this is more than a single object as transactions, connections, etc. are involved.