I work for a small company. We have under 300 users. We are in the process of designing our first DAL. My boss has decided that the DAL will use a Typed Dataset as a Data Transfer Object. In addition this DataSet will have methods to handle all CRUD operations.
We have a decision to make and could use some direction.
We are not sure which of these is best:
a) One Dataset that directly mirrors the structure of my database and therefore has a data table for each table in our database.
b) One Dataset per database table.
c) One Dataset per business object. This dataset would be used to handle all of the CRUD operations on the business object. This dataset could in fact contain more then one data table
d) One DataSet per Web Page. This dataset would handle any CRUD operations required on the Web Page.
I would appreciate it if I could get some pro's and con's to each of these methods so that I could present them to my boss. I would also appreciate it if someone has a better idea.
If you must use typed datasets, my recommendation would be B. A would make it too bloated. C and D might lead to problems down the road when a two web pages / business objects use the same database tables for different purposes.
Thanks for the answer. I am curious as to what you would recommend instead of typed datasets?
DataSet is just in memory database, and database is designed to stored your data, not model your business process. Use business objects and you can get a lot of benefits from OO world.
Li Xin
Get it Done! Simple is Best!
LatticeFramework Studio - model-driven template-based code generator
I would like to use business objects. Before I can convince my boss, I have a few questions that I am having trouble getting answers too.
1. Am I correct that if I am forced to use datasets, that typed datasets are preferrable to untyped datasets?
2. Some of my team believes that there is always a one to one coorelation from a business object to a database table. In other words each business object can perform CRUD operations to one and only one table. Is this correct or can a business object possibly
perform CRUD operations on more then one table? I am asking because other members of the team feel that there does not have to be any correlation between database tables and a business object whatsoever. That the business class can span as many tables as
needed to support the business classes functionality. Who is correct?
1) Typed data is almost always prefferable to untyped data.
2) Business objects can span tables. You may start out constructing your objects to map directly to your tables, but you may then eventually find a need to alter one of the objects to become a Composite object. The composite is a business object that contains
one or more other business objects that get stored in other tables.
A simple example is: a customer object that contains multiple address objects.
Also, you state: each business object can perform CRUD operations
I would not put the CRUD into each business object. I would avoid code like this:
myObject.Load
myObject.Save
Instead, use a manager class to load and persist your objects
myObject = myObjectManager.Load(someId)
myObjectCollection = myManager.LoadCollection()
myObjectManager.Save(myObject)
Thanks so much. Now all I have to do is to convince my boss.
The interesting thing is that my original design matched your design. For each database table, I had 3 classes; an entity class, an entity collection class and a manager class which handled all CRUD operations on the entity classes.
My boss shot down this design because he felt that with typed datasets we could develop our system faster than by using business classes. He wants to either bypass the business layer altogether or to extend the functionality of the typed dataset by adding
our business rules to the typed datasets by creating partial classes on the data tables within the typed dataset.
> Am I correct that if I am forced to use datasets
Why so? In instance, i prefer wrapping my db in Stored Procedures and having a DAL with static methods mapping to the SPs. That, in my opinion, better maps to my business domain, which is procedural rather than else.
> that typed datasets are preferrable to untyped datasets?
Strong typing helps getting errors early at compile time, so it is usually preferred.
> Some of my team believes that there is always a one to one coorelation from a business object to a database table.
Well, maybe they mean "business data-objects", which is something you collect at business analysis level, and is a data concept. Instead "business objects" lay into the so called Business Layer and come in place when later architecting and designing your
application. So a business object does not need to map to a table or even to a procedure; it rather leverages them to perform its purpose.
Thanks for the advise. I am not sure what you mean by wrapping your DB in stored procedures. If you mean that the only access to your database is via stored procedures, we do the same thing. Do you use one DAL to access all of your stored procs, or one
DAL per database table?
My boss read some place that Microsoft believes that all data should be transferred from layer to layer via datasets (or data tables). 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. Since I believe that we need to introduce at least a little business logic, I have convinced him that on the UI we need to map the data tables to a business object for the
purposes of applying business rules.
For example: My UI code will look something like this:
CustomerDataSet custDS = new CustomerDataSet();
CustomerDataTable custD = new CustomerDataTable();
custDT = custDS.GetCustomer(100);
Customer cust = new Customer(custDT.id, custDT.name, custDT.address);
cust.Address = "Some New Value"
custDS.Update(cust);
Does this make any sense? Will it work for a small system?
My boss read some place that Microsoft believes that all data should be transferred from layer to layer via datasets (or data tables).
For example: My UI code will look something like this:
CustomerDataSet custDS = new CustomerDataSet();
CustomerDataTable custD = new CustomerDataTable();
custDT = custDS.GetCustomer(100);
Customer cust = new Customer(custDT.id, custDT.name, custDT.address);
cust.Address = "Some New Value"
custDS.Update(cust);
Does this make any sense? Will it work for a small system?
Thanks
I suppose it works for a small system. I really hesitate to couple everything into the dataset class. My issue is, if you ever have to regenerate it because of a change in the fields, you end up with a hassle. That, and the fact that it's more copy/paste
programming than modular/encapsulated.
mikener
Member
534 Points
238 Posts
Data Access Design Question
Apr 19, 2006 03:22 PM|LINK
I work for a small company. We have under 300 users. We are in the process of designing our first DAL. My boss has decided that the DAL will use a Typed Dataset as a Data Transfer Object. In addition this DataSet will have methods to handle all CRUD operations. We have a decision to make and could use some direction.
We are not sure which of these is best:
a) One Dataset that directly mirrors the structure of my database and therefore has a data table for each table in our database.
b) One Dataset per database table.
c) One Dataset per business object. This dataset would be used to handle all of the CRUD operations on the business object. This dataset could in fact contain more then one data table
d) One DataSet per Web Page. This dataset would handle any CRUD operations required on the Web Page.
I would appreciate it if I could get some pro's and con's to each of these methods so that I could present them to my boss. I would also appreciate it if someone has a better idea.
Thanks
TAsunder
Participant
1001 Points
215 Posts
Re: Data Access Design Question
Apr 19, 2006 09:35 PM|LINK
mikener
Member
534 Points
238 Posts
Re: Data Access Design Question
Apr 20, 2006 02:12 AM|LINK
latticesoft
Participant
1493 Points
335 Posts
Re: Data Access Design Question
Apr 20, 2006 02:48 AM|LINK
DataSet is just in memory database, and database is designed to stored your data, not model your business process. Use business objects and you can get a lot of benefits from OO world.
Get it Done! Simple is Best!
LatticeFramework Studio - model-driven template-based code generator
mikener
Member
534 Points
238 Posts
Re: Data Access Design Question
Apr 20, 2006 01:18 PM|LINK
I would like to use business objects. Before I can convince my boss, I have a few questions that I am having trouble getting answers too.
1. Am I correct that if I am forced to use datasets, that typed datasets are preferrable to untyped datasets?
2. Some of my team believes that there is always a one to one coorelation from a business object to a database table. In other words each business object can perform CRUD operations to one and only one table. Is this correct or can a business object possibly perform CRUD operations on more then one table? I am asking because other members of the team feel that there does not have to be any correlation between database tables and a business object whatsoever. That the business class can span as many tables as needed to support the business classes functionality. Who is correct?
Thanks
mbanavige
All-Star
134964 Points
15421 Posts
ASPInsiders
Moderator
MVP
Re: Data Access Design Question
Apr 20, 2006 04:20 PM|LINK
1) Typed data is almost always prefferable to untyped data.
2) Business objects can span tables. You may start out constructing your objects to map directly to your tables, but you may then eventually find a need to alter one of the objects to become a Composite object. The composite is a business object that contains one or more other business objects that get stored in other tables.
A simple example is: a customer object that contains multiple address objects.
Also, you state: each business object can perform CRUD operations
I would not put the CRUD into each business object. I would avoid code like this:
myObject.Load
myObject.Save
Instead, use a manager class to load and persist your objects
myObject = myObjectManager.Load(someId)
myObjectCollection = myManager.LoadCollection()
myObjectManager.Save(myObject)
mikener
Member
534 Points
238 Posts
Re: Data Access Design Question
Apr 20, 2006 06:37 PM|LINK
Thanks so much. Now all I have to do is to convince my boss.
The interesting thing is that my original design matched your design. For each database table, I had 3 classes; an entity class, an entity collection class and a manager class which handled all CRUD operations on the entity classes.
My boss shot down this design because he felt that with typed datasets we could develop our system faster than by using business classes. He wants to either bypass the business layer altogether or to extend the functionality of the typed dataset by adding our business rules to the typed datasets by creating partial classes on the data tables within the typed dataset.
Thanks again.
LudovicoVan
Star
9692 Points
1935 Posts
Re: Data Access Design Question
Apr 20, 2006 10:41 PM|LINK
mikener:
> Am I correct that if I am forced to use datasets
Why so? In instance, i prefer wrapping my db in Stored Procedures and having a DAL with static methods mapping to the SPs. That, in my opinion, better maps to my business domain, which is procedural rather than else.
> that typed datasets are preferrable to untyped datasets?
Strong typing helps getting errors early at compile time, so it is usually preferred.
> Some of my team believes that there is always a one to one coorelation from a business object to a database table.
Well, maybe they mean "business data-objects", which is something you collect at business analysis level, and is a data concept. Instead "business objects" lay into the so called Business Layer and come in place when later architecting and designing your application. So a business object does not need to map to a table or even to a procedure; it rather leverages them to perform its purpose.
-LV
mikener
Member
534 Points
238 Posts
Re: Data Access Design Question
Apr 21, 2006 01:00 PM|LINK
Thanks for the advise. I am not sure what you mean by wrapping your DB in stored procedures. If you mean that the only access to your database is via stored procedures, we do the same thing. Do you use one DAL to access all of your stored procs, or one DAL per database table?
My boss read some place that Microsoft believes that all data should be transferred from layer to layer via datasets (or data tables). 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. Since I believe that we need to introduce at least a little business logic, I have convinced him that on the UI we need to map the data tables to a business object for the purposes of applying business rules.
For example: My UI code will look something like this:
CustomerDataSet custDS = new CustomerDataSet();
CustomerDataTable custD = new CustomerDataTable();
custDT = custDS.GetCustomer(100);
Customer cust = new Customer(custDT.id, custDT.name, custDT.address);
cust.Address = "Some New Value"
custDS.Update(cust);
Does this make any sense? Will it work for a small system?
Thanks
TAsunder
Participant
1001 Points
215 Posts
Re: Data Access Design Question
Apr 21, 2006 05:28 PM|LINK
I suppose it works for a small system. I really hesitate to couple everything into the dataset class. My issue is, if you ever have to regenerate it because of a change in the fields, you end up with a hassle. That, and the fact that it's more copy/paste programming than modular/encapsulated.