I tend to agree with you. My boss on the other hand likes this copy/paste approach since it could bring the system to production a little more quickly. I will pass along your 'regeneration' issue. That might sway him.
Some of the reading that I have done as of last seems to indicated that datasets in .NET 2.0 are far superior to the 1.1 version. I am wondering if that is true or it is just hype.
Are you aware of any good products that I could recommend that would build a good data layer based on a database schema? I might be able to sell that as a solution.
> Do you use one DAL to access all of your stored procs, or one DAL per database table?
A DAL is a layer, not a class, so this question does not make very much sense. My DAL is a procedural-wrapper/data-mapper to the data store. Its purpose is hiding data store specifics, so that you could even plug and play DALs accessing different kinds of
data stores (db, xml files, remote services, etc.) provided that they keep the same public interface to expose to upper layers.
This said, i structure my classes and methods into DAL following the data store structure as exposed from Stored Procedures. And how about SPs structure? Well, my approach is process-centric, mostly inspired by business analysis and the processes/data-objects
defined there. In practice, say you have these 2-3 SPs to handle web users (web access, profile read and update, etc.); than i'd have a "User" class basically exposing 2-3 static methods... Here i'd stress this "User" class does *not* map to any User table,
which could even not exist; it rather refers to the "process of handling users, and related tasks"! (I.e. process <=> class, task <=> class method. Here we also get a connection to use cases, if we like...)
> My boss read some place that Microsoft believes that all data should be transferred from layer to layer via datasets (or data tables).
The problem maybe is that Microsoft publishes both advanced and introductory documentation, where you can find sophisticated architectures near simple RAD approaches without additional warnings, and the beginner gets lost (mho). Anyway i don't think they
may have ever asserted something like that. That rather you can read in Architecture discussions.
> At this point the design consists of one dataset with one data table per database table. That dataset will have methods to perform all CRUD operations by executing stored procs on the underlying database.
Now that you know my approach is process centric, you can get why i don't really like talking about CRUD. What's CRUD after all? I've never experienced any "pure" CRUD against the data store in my applications! Thinking in terms of CRUD + "the rest" becomes
meaningful only in case you consider your database a bunch of tables and nothing more.
> My boss on the other hand likes this copy/paste approach since it could bring the system to production a little more quickly.
Where's the copy/paste? Reuse is quite a tough and serious matter. Copy/paste is ok as far as you everyday work to minimize the amount... restructuring backwards before you do it! Going to production quickly while not compromising the architecture and the
future of the project can be done with an incremental approach, plus eventually prototyping. Maybe check with your boss for the Extreme Programming concepts... ;)
First, let me say that I mis stated what I meant about the DAL being a class. What I meant to ask was whether or not the DAL (which I have setup as a DLL) is comprised of a series of classes that wrap my stored procedures based on business functionality
or one class that wraps all of my stored procedures without regard to business functionality. In another forum I was told that one class wrapping all of my stored procs was a good idea. This seems like it could cause problems in the future.
Your process centric approach seems like a good way to go. Many people have recommended a data centric approach. That was why I had asked if a business class can or should span more then one database table. It seems to me the business class should span
as many tables as needed to support the business class. The one caveat to that is that one gentlemen suggested that since I and the members of my team are new to this OO stuff that we might be better off initially having a one business class to one database
table. That once we got a little more experience we could then move to the process centric approach that you favor. This seems to me like a good way to get started.
I also wanted to thank you for taking the time to respond to my questions. While I understand from a conceptual point of view how OO works, putting it into practice is a bit of a challenge.
> While I understand from a conceptual point of view how OO works, putting it into practice is a bit of a challenge.
I'd just like to worn you OO belongs to a later phase than architecture. OO is about implementation, while architecture is implementation independent. So i'd say feel free to architecture your system as it diserves, with its net of components over layers,
each with its own definite purpose. There's no reason to compromise at this level. Then comes technical design and coding, and there you might start with basic OO features, that is structured programming with encapsulation.
When I first started with .NET my bosses introduced me to 3-Tier development. Since then, on mid-enterprise applications I will always work with nTier architecture.
Microsoft had a good article on how to design a DataAccess layer, wish I was at work where I have it bookmarked... anyways,
Since our new application rewrites have started we built wrappers around ADO.NET. That is our Core DataAccess layer. we also have a DataObject Layer that defines objects that are passed between Data and Busines layer.
We've found the above the best way. Our application deals with over 200 tables and 700 stored procedures so we need it to be extremely flexible... especially with customers who want a web application that can predict the future as well as fix all the problems
they have with their job :(
The Killer Ninja Coding Monkeys thank those that mark helpful posts as answers.
mikener
Member
534 Points
238 Posts
Re: Data Access Design Question
Apr 21, 2006 06:36 PM|LINK
I tend to agree with you. My boss on the other hand likes this copy/paste approach since it could bring the system to production a little more quickly. I will pass along your 'regeneration' issue. That might sway him.
Some of the reading that I have done as of last seems to indicated that datasets in .NET 2.0 are far superior to the 1.1 version. I am wondering if that is true or it is just hype.
Are you aware of any good products that I could recommend that would build a good data layer based on a database schema? I might be able to sell that as a solution.
Thanks
LudovicoVan
Star
9692 Points
1935 Posts
Re: Data Access Design Question
Apr 22, 2006 01:25 PM|LINK
> Do you use one DAL to access all of your stored procs, or one DAL per database table?
A DAL is a layer, not a class, so this question does not make very much sense. My DAL is a procedural-wrapper/data-mapper to the data store. Its purpose is hiding data store specifics, so that you could even plug and play DALs accessing different kinds of data stores (db, xml files, remote services, etc.) provided that they keep the same public interface to expose to upper layers.
This said, i structure my classes and methods into DAL following the data store structure as exposed from Stored Procedures. And how about SPs structure? Well, my approach is process-centric, mostly inspired by business analysis and the processes/data-objects defined there. In practice, say you have these 2-3 SPs to handle web users (web access, profile read and update, etc.); than i'd have a "User" class basically exposing 2-3 static methods... Here i'd stress this "User" class does *not* map to any User table, which could even not exist; it rather refers to the "process of handling users, and related tasks"! (I.e. process <=> class, task <=> class method. Here we also get a connection to use cases, if we like...)
> My boss read some place that Microsoft believes that all data should be transferred from layer to layer via datasets (or data tables).
The problem maybe is that Microsoft publishes both advanced and introductory documentation, where you can find sophisticated architectures near simple RAD approaches without additional warnings, and the beginner gets lost (mho). Anyway i don't think they may have ever asserted something like that. That rather you can read in Architecture discussions.
> At this point the design consists of one dataset with one data table per database table. That dataset will have methods to perform all CRUD operations by executing stored procs on the underlying database.
Now that you know my approach is process centric, you can get why i don't really like talking about CRUD. What's CRUD after all? I've never experienced any "pure" CRUD against the data store in my applications! Thinking in terms of CRUD + "the rest" becomes meaningful only in case you consider your database a bunch of tables and nothing more.
> My boss on the other hand likes this copy/paste approach since it could bring the system to production a little more quickly.
Where's the copy/paste? Reuse is quite a tough and serious matter. Copy/paste is ok as far as you everyday work to minimize the amount... restructuring backwards before you do it! Going to production quickly while not compromising the architecture and the future of the project can be done with an incremental approach, plus eventually prototyping. Maybe check with your boss for the Extreme Programming concepts... ;)
-LV
mikener
Member
534 Points
238 Posts
Re: Data Access Design Question
Apr 22, 2006 07:48 PM|LINK
First, let me say that I mis stated what I meant about the DAL being a class. What I meant to ask was whether or not the DAL (which I have setup as a DLL) is comprised of a series of classes that wrap my stored procedures based on business functionality or one class that wraps all of my stored procedures without regard to business functionality. In another forum I was told that one class wrapping all of my stored procs was a good idea. This seems like it could cause problems in the future.
Your process centric approach seems like a good way to go. Many people have recommended a data centric approach. That was why I had asked if a business class can or should span more then one database table. It seems to me the business class should span as many tables as needed to support the business class. The one caveat to that is that one gentlemen suggested that since I and the members of my team are new to this OO stuff that we might be better off initially having a one business class to one database table. That once we got a little more experience we could then move to the process centric approach that you favor. This seems to me like a good way to get started.
I also wanted to thank you for taking the time to respond to my questions. While I understand from a conceptual point of view how OO works, putting it into practice is a bit of a challenge.
LudovicoVan
Star
9692 Points
1935 Posts
Re: Data Access Design Question
Apr 22, 2006 10:10 PM|LINK
> While I understand from a conceptual point of view how OO works, putting it into practice is a bit of a challenge.
I'd just like to worn you OO belongs to a later phase than architecture. OO is about implementation, while architecture is implementation independent. So i'd say feel free to architecture your system as it diserves, with its net of components over layers, each with its own definite purpose. There's no reason to compromise at this level. Then comes technical design and coding, and there you might start with basic OO features, that is structured programming with encapsulation.
Best regards. -LV
mikener
Member
534 Points
238 Posts
Re: Data Access Design Question
Apr 22, 2006 10:54 PM|LINK
RTernier
Contributor
4755 Points
1139 Posts
Re: Data Access Design Question
Apr 24, 2006 03:17 AM|LINK
Microsoft had a good article on how to design a DataAccess layer, wish I was at work where I have it bookmarked... anyways,
Since our new application rewrites have started we built wrappers around ADO.NET. That is our Core DataAccess layer. we also have a DataObject Layer that defines objects that are passed between Data and Busines layer.
We've found the above the best way. Our application deals with over 200 tables and 700 stored procedures so we need it to be extremely flexible... especially with customers who want a web application that can predict the future as well as fix all the problems they have with their job :(
My Site | My Examples | My Blog
thona
Member
20 Points
2923 Posts
Re: Data Access Design Question
Apr 24, 2006 04:50 AM|LINK
Suggested Reading:
In that order. You will find it a LOT less of a challenge then.
RTernier
Contributor
4755 Points
1139 Posts
Re: Data Access Design Question
Apr 24, 2006 03:24 PM|LINK
Here's the link to the article I mentioned in my above post:
Designing Data Tier Components and Passing Data Through Tiers
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/BOAGag.asp
My Site | My Examples | My Blog
mikener
Member
534 Points
238 Posts
Re: Data Access Design Question
Apr 25, 2006 01:12 PM|LINK
mikener
Member
534 Points
238 Posts
Re: Data Access Design Question
Apr 25, 2006 01:14 PM|LINK
Great article. I just finished it.
Thanks.