There are a few people on this forum that have some pretty strong opinions against DataSets, and in many regards, their criticisms are correct. However, many of the criticisms present on this forum are simply inaccurate. Here are some statements I have recently
read regarding DataSets:
"Datasets do not handle lazy load scenarios well - you have to have all related items in the dataset."
This is only true if the DataRelation is set to enforce it's constraints. Unfortunately, this is the default setting of the DataSet creation tool in VisualStudio, and it does cause annoying run time errors when you are trying to use lazy loading. However, this
is a usage issue, not an issue with datasets, it is very simple to modify a DataRelation to be friendly to lazy loading. This task can be extremely simple if you use a customized DataSet creator. (Less than 20 lines of code...)
Strongly typed datasets perform slower than weakly typed datasets.
This statement is true in some respects, and slanderous in others. A strongly typed dataset generally holds ALL tables and ALL columns for the schema it was generated from. For this reason, instantiating a strongly typed dataset can be considerably more costly
than instanciating a normal dataset. However, a strongly typed dataset has explicit DataColumn and DataRelation objects defined for every column and relation that increase the speed of referencing row values and relations using the strongly typed methods...
So, the more often you use a DataSet, and the more rarely you create or destroy them, the better a strongly typed DataSet will serve you.
DataSets are a no-no with ASP.Net...
This statement assumes that all ASP.Net applications do the same things. Straight datareader calls are always ligher than a data adapter call, but usage of data sets can dramatically reduce the number of trips to the database you
take... more than making up for their overhead. Studies that compare DataReaders vs DataSets with DataAdapters (typically) only measure the data access times. If you implement your own data objects (or create them with an ORM) and your data objects manage relationships,
data versions, and other features that are present in a DataSet, then you are adding overhead that is not measured in the initial comparison. If your ASP.Net application allows users to edit a series of values (across multiple forms) and save them as a transaction
then a DataSet / DataAdapter solution will outperform a DataReader / Custom Data Object solution in most situations.
If you are creating a new DataSet with every page request and loading it with data, just to dereference it at the end of the page request then you should be using a DataReader with a simpler data object. If you are caching a collection of hand crafted data
objects betwee page requests to hold state then you should consider if using DataSets and DataAdaptors will save you maintenance or enchancement time. If you are using an OR Mapper that meets all your needs, then concider yourself lucky that your needs are
met: but don't assume that is the only solution for your needs.
DataSets are not evil, they are VERY capable data objects. Those that critique DataSet object vs custom Business Objects miss the point that neither should compete with the other, and neither is exclusive of the other. I use ORMappers, but my ORMapper is used
to generate separate data objects and business objects. Those data objects are commonly subclasses of the System.Data classes.
Lastly, if you have written an ORM, and your actively selling it, then continue degrading the dataset; it is nowhere near as powerful as your ORM. Sure, it is an apple vs. oranges comparison; but if people learn how to use a dataset properly they may realize
that it is a very effective data object that marginally undermines the benefits of your tool.
Sean, IF you argument for the DataSet, then do it properly.
"Datasets do not handle lazy load scenarios well - you have to have all related items in the dataset." This is only true if the DataRelation is set to enforce it's constraints.
No, it is true always. The DataSet has no support for lazy load operation in atransparent way. ALL data has to be manually loaded by the user. The contraint enforcement is a pain in the ass to deal with it, but you can turn it off. This, though, will not magically
make data appear. DataSets are the dumpest form of data container you can have. They know onyl the absolute minumum they need to know, and have only the absolute minimum functionality. Now, this is fine - but it does not make all the other stuff magically
appear.
The other statements I have never heard.
I use ORMappers, but my ORMapper is used to generate separate data objects and business objects. Those data objects are commonly subclasses of the System.Data classes.
Then let me tell you your O/R mapper is a toy, as it does with a very high propability NOT deal with one of the most fundamental things: inheritance. If I ask for a list of ContentItems, and the list contains anything BUT content items (as the class is abstract,
but has about 100 subclasses, most with additional data and all of them overriding common functionality besides implementing their own functionality), THEN I have an O/R mapper. And this can simply not be done with datasets. So, Any O/R mapper that does not
do sobasically deals with no data driven inheritance, taking about the biggest advatage out. It means you are not an O/R mapper, but more an ORM-Mapper, mapping table structures intstead of object structures.
For me, in any nontrivial application, I would not want to ever deal with something that does not make data driven inheritance.
but if people learn how to use a dataset properly they may realize that it is a very effective data object that marginally undermines the benefits of your tool.
Just a question - have you ever developped al arger application? I mean something with let's say 150+ business objects mapping data from about 100+ tables, with inheritance hierarchies about a half a dozen levels deep (data driven)? In
proper OO code?
If you have not - then what about you get the experience before degrading superior solutions?
I love the dataset. The dataset is a perfect example of how you can store relational data for a laye higher up. Sadly, I am not dealing with relational data - I deal with object oriented applications. There, using a dataset as replacement for a real object
model is an attitude that - well, elt's say the moderators would not approove this post if I would tell what I seriously think about it.
Datasets are ´fine for what they do. Just - what they do is not what an application programmer wants.
We are adding, to the EntityBroker 3, a reporting interface. Guess what it will return - datasets. It makes perfect sense there, to get a tabular reporting form of "Data" - data has no logic attached, knows no inheritance. But my transactions continue to use
a strong typed object model that knows data driven inheritance.
One of my biggest dislikes about this forum is the vested interests that many posters display. Its becoming more and more like an advertising forum, where the answer to every question posted is 'buy an O/R mapper', usually posted by one of the 4 main vendors.
I've used O/R mappers, Datasets and EntLib in Enterprise applications all with great success. I've made my own judgment as to which is best in which scenario, I suggest that everybody does the same, and to not just think that O/R mappers are a panacea because
someone else says so.
Jon Paul Davies - Liverpool UK
www.j-dee.com .NET weblog
Always keep an open mind and use the best tools available for the project. ADO.NET components, O/R mapper and EntLib are equally important tools built for very important purpose. Try not to listen to vendors or saleman unless they are soundly convincible. I
hope that this forum would not turn into an advertising forum and I'm sure moderator of this forum would not want it to be. In the meantime, let's have fun, learn and share the best we have.
Sean, IF you argument for the DataSet, then do it properly.
I'm not arguing for the DataSet. I'm just trying to offer an experienced counterpoint.
"Datasets do not handle lazy load scenarios well - you have to have all related items in the dataset." This is only true if the DataRelation is set to enforce it's constraints.
No, it is true always. The DataSet has no support for lazy load operation in atransparent way. ALL data has to be manually loaded by the user.
The contraint enforcement is a pain in the ass to deal with it, but you can turn it off. This, though, will not magically make data appear. DataSets are the dumpest form of data container you can have. They know onyl the absolute minumum they need to know,
and have only the absolute minimum functionality. Now, this is fine - but it does not make all the other stuff magically appear.
You are mistaken. In the constructor for the DataRelation, the last argument is a boolean that specifies whether the relation should be enforced... If you create the relation and specify false, then you can still retrieve data using the data relation. You can
specify computed columns using the relation. It is true that a DataSet doesn't load data automatically for you, but that really is not a data objects responsibility. IMHO it is a good thing that the data object only knows what they need to know.
I use ORMappers, but my ORMapper is used to generate separate data objects and business objects. Those data objects are commonly subclasses of the System.Data classes.
Then let me tell you your O/R mapper is a toy, as it does with a very high propability NOT deal with one of the most fundamental things: inheritance. If I ask for a list of ContentItems, and the list contains anything BUT content items
(as the class is abstract, but has about 100 subclasses, most with additional data and all of them overriding common functionality besides implementing their own functionality), THEN I have an O/R mapper. And this can simply not be done with datasets. So,
Any O/R mapper that does not do sobasically deals with no data driven inheritance, taking about the biggest advatage out. It means you are not an O/R mapper, but more an ORM-Mapper, mapping table structures intstead of object structures.
For me, in any nontrivial application, I would not want to ever deal with something that does not make data driven inheritance.
Nothing in my statements above should have led you to believe the ORMs I was speaking of did not support inheritence. As a matter of fact, they handle inheritance (both explicitly configured, and data schema defined inheritance) well. They use System.Data based
objects ONLY in the data layer, not in the business layer. The business objects manipulate the data objects to reflect their business rules, they are not derived from data objects.
If your OR Mapper tightly couples your business objects and their inheritance tree to your data objects, then I could argue that your OR Mapper is a toy. However, I don't want to influence others with my speculation.
Just a question - have you ever developped al arger application? I mean something with let's say 150+ business objects mapping data from about 100+ tables, with inheritance hierarchies about a half a dozen levels deep (data driven)? In
proper OO code?
If you have not - then what about you get the experience before degrading superior solutions?
150+ business objects and 100+ tables is a small to average sized application in my book. I don't want to get into a credentials contest however.
Applications do not have to be "relational" OR "object oriented". A well designed application is actually an interweaving of small, sefl consistent parts. The parts in the applications I have worked on in the past were comprised of data layer portions that
were relational, and business layer portions that were object oriented. "Relational" AND "Object oriented".
I love the dataset. The dataset is a perfect example of how you can store relational data for a laye higher up. Sadly, I am not dealing with relational data - I deal with object oriented applications. There, using a dataset as replacement
for a real object model is an attitude that - well, elt's say the moderators would not approove this post if I would tell what I seriously think about it.
Datasets are ´fine for what they do. Just - what they do is not what an application programmer wants.
We are adding, to the EntityBroker 3, a reporting interface. Guess what it will return - datasets. It makes perfect sense there, to get a tabular reporting form of "Data" - data has no logic attached, knows no inheritance. But my transactions continue to use
a strong typed object model that knows data driven inheritance.
It is clear to me that we view the responsibilities of the different layers of an application differently. It sounds like your business layer and your data layer are more tightly coupled than I would like. In my experience business layer objects should manipulate
data layer objects, but should not reflect their structure in anyway, unless it makes business sense for them to do so.
I agree with you that a mapping layer is required, I just don't believe that the mapping should be performed between the database and the data layer. I am willing to concede that optimal point to perform this mapping may fluctuate from application to application
or problem domain to problem domain. I do not conceed that choosing to use System.Data based objects in your data layer has any real bearing on where that mapping is performed.
Always keep an open mind and use the best tools available for the project. ADO.NET components, O/R mapper and EntLib are equally important tools built for very important purpose. Try not to listen to vendors or saleman unless they are soundly convincible. I
hope that this forum would not turn into an advertising forum and I'm sure moderator of this forum would not want it to be. In the meantime, let's have fun, learn and share the best we have.
One of my biggest dislikes about this forum is the vested interests that many posters display. Its becoming more and more like an advertising forum, where the answer to every question posted is 'buy an O/R mapper', usually posted by one of the 4 main vendors.
and
Thanhq
Always keep an open mind and use the best tools available for the project. ADO.NET components, O/R mapper and EntLib are equally important tools built for very important purpose. Try not to listen to vendors or saleman unless they are soundly convincible. I
hope that this forum would not turn into an advertising forum and I'm sure moderator of this forum would not want it to be. In the meantime, let's have fun, learn and share the best we have.
The sad thing is though that some anti-O/R mapper people play the 'You're biased!!' card when they don't agree with what an O/R mapper person has to say.
Also, the average developer here hasn't spend 3+ years full time (that's 5-7 days a week, 8+hours a day) on data-access and O/R mapping. Most O/R mapper vendors here have. They have waded through almost all problems data-access code will run into and more,
far more than most of the people here ever will run into.
Needless to say, these people know what they're talking about.
The people who for example think I post here just to be the salesman, have no clue whatsoever and frankly aren't worth a second of my time, because most O/R mapper vendors here, including myself, aren't posting here to increase sales, we're posting here because
we have the knowledge others ask for, as it's our day to day core topic of interest: solving the data-access problem, and so we give that knowledge to you.
Also, this forum is like this for a couple of years now, so I don't think it will fall apart as an advertising forum.
I do get a little bit tired though that O/R mapper vendors always have to defend their own opinion against bias and "you're advertising your own stuff!"-kinda crap.
For example, I never posted "You should buy the O/R mapper <insert brand here>"!!. It's acquisations like the one posted by JDee which make it more and more tiresome to discuss data-access related problems without having to deal with "You're biased", holy houses
or other sillyness, instead of discussing the real matter and the real point.
If your argument is solely based on the fact that O/R mapper-oriented advice is biased and therefore should be ignored, realize that this forum isn't helped by that kind of attitude and neither are the ones asking a question or starting the discussion.
I mean, look at this discussion, it starts to look like a stored procedure vs. dyn. SQL discussion almost instantly. "AMD is better!!" "No!! nVidia!!"
...
Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
LLBLGen Pro website: http://www.llblgen.com My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
I wasn't trying to turn this discussion into a DataSet vs OR Mapper discussion. On the contrary, I was trying to convey that they are not opposed to one another at all. It is great of you and the other ORM vendors to come here and share your knowledge with
us, and these boards would not be so popular without you all. I was hoping to address some of the overgeneralized criticisms of the DataSet, because it would be a shame one of thoese less experienced developers here completely overlooked it due to opinions
they read here.
>>The sad thing is though that some anti-O/R mapper people play the 'You're biased!!' card when they don't agree with what an O/R >>mapper person has to say.
Where on earth did you get the idea that I'm anti O/R mapper?? For your info Frans, I'm a happy fully paid up customer of yours. Read my post again and next time don't just quote the parts that suit your argument. Quote the part that says I'm fully aware of
the advantages and disadvantages of ALL data access methodologies and that I choose the best one on a per project basis too.
>>For example, I never posted "You should buy the O/R mapper <insert brand here>"!!.
>>The people who for example think I post here just to be the salesman,
Ok, fair comment, but lets not be naive, we ALL know vendors who DO.with.tiresome...zzzz...crass....snore...regularity.....
>>Needless to say, these people know what they're talking about.
What? 100%? All the time? I should believe without question? Look at Sean's reply. I've done my own tests and drawn my own conclusions.
>>It's acquisations like the one posted by JDee which make it more and more tiresome to discuss data-access related problems without >>having to deal with "You're biased",
touche' - count the amount of 'You're biased' posts, and then count the amount of 'buy an O/R mapper' posts and you'll really see who is tired..... sprocs, ad-hoc sql, datasets, doing away with objects alltogether and writing strictly procedural code - they
all have their uses, advantages and disadvantages.
Anyway, if anyone is interested I'll finish up with a quote from The Pragmatic Programmer by Andrew Hunt & David Thomas:
"Critically Analyze What You Read and Hear. Don't be swayed by vendors, media hype, or dogma. Analyze information in terms of you and your project."
Jon Paul Davies - Liverpool UK
www.j-dee.com .NET weblog
SeanSmith
Member
110 Points
22 Posts
Defending the DataSet: Agreeing to Disagree...
Jun 29, 2005 12:26 AM|LINK
There are a few people on this forum that have some pretty strong opinions against DataSets, and in many regards, their criticisms are correct. However, many of the criticisms present on this forum are simply inaccurate. Here are some statements I have recently read regarding DataSets:
"Datasets do not handle lazy load scenarios well - you have to have all related items in the dataset."
This is only true if the DataRelation is set to enforce it's constraints. Unfortunately, this is the default setting of the DataSet creation tool in VisualStudio, and it does cause annoying run time errors when you are trying to use lazy loading. However, this is a usage issue, not an issue with datasets, it is very simple to modify a DataRelation to be friendly to lazy loading. This task can be extremely simple if you use a customized DataSet creator. (Less than 20 lines of code...)
Strongly typed datasets perform slower than weakly typed datasets.
This statement is true in some respects, and slanderous in others. A strongly typed dataset generally holds ALL tables and ALL columns for the schema it was generated from. For this reason, instantiating a strongly typed dataset can be considerably more costly than instanciating a normal dataset. However, a strongly typed dataset has explicit DataColumn and DataRelation objects defined for every column and relation that increase the speed of referencing row values and relations using the strongly typed methods... So, the more often you use a DataSet, and the more rarely you create or destroy them, the better a strongly typed DataSet will serve you.
DataSets are a no-no with ASP.Net...
This statement assumes that all ASP.Net applications do the same things. Straight datareader calls are always ligher than a data adapter call, but usage of data sets can dramatically reduce the number of trips to the database you take... more than making up for their overhead. Studies that compare DataReaders vs DataSets with DataAdapters (typically) only measure the data access times. If you implement your own data objects (or create them with an ORM) and your data objects manage relationships, data versions, and other features that are present in a DataSet, then you are adding overhead that is not measured in the initial comparison. If your ASP.Net application allows users to edit a series of values (across multiple forms) and save them as a transaction then a DataSet / DataAdapter solution will outperform a DataReader / Custom Data Object solution in most situations.
If you are creating a new DataSet with every page request and loading it with data, just to dereference it at the end of the page request then you should be using a DataReader with a simpler data object. If you are caching a collection of hand crafted data objects betwee page requests to hold state then you should consider if using DataSets and DataAdaptors will save you maintenance or enchancement time. If you are using an OR Mapper that meets all your needs, then concider yourself lucky that your needs are met: but don't assume that is the only solution for your needs.
DataSets are not evil, they are VERY capable data objects. Those that critique DataSet object vs custom Business Objects miss the point that neither should compete with the other, and neither is exclusive of the other. I use ORMappers, but my ORMapper is used to generate separate data objects and business objects. Those data objects are commonly subclasses of the System.Data classes.
Lastly, if you have written an ORM, and your actively selling it, then continue degrading the dataset; it is nowhere near as powerful as your ORM. Sure, it is an apple vs. oranges comparison; but if people learn how to use a dataset properly they may realize that it is a very effective data object that marginally undermines the benefits of your tool.
thona
Member
10 Points
2923 Posts
Re: Defending the DataSet: Agreeing to Disagree...
Jun 29, 2005 01:54 PM|LINK
Sean, IF you argument for the DataSet, then do it properly.
"Datasets do not handle lazy load scenarios well - you have to have all related items in the dataset."
This is only true if the DataRelation is set to enforce it's constraints.
No, it is true always. The DataSet has no support for lazy load operation in atransparent way. ALL data has to be manually loaded by the user. The contraint enforcement is a pain in the ass to deal with it, but you can turn it off. This, though, will not magically make data appear. DataSets are the dumpest form of data container you can have. They know onyl the absolute minumum they need to know, and have only the absolute minimum functionality. Now, this is fine - but it does not make all the other stuff magically appear.
The other statements I have never heard.
I use ORMappers, but my ORMapper is used to generate separate data objects and business objects. Those data objects are commonly subclasses of the System.Data classes.
Then let me tell you your O/R mapper is a toy, as it does with a very high propability NOT deal with one of the most fundamental things: inheritance. If I ask for a list of ContentItems, and the list contains anything BUT content items (as the class is abstract, but has about 100 subclasses, most with additional data and all of them overriding common functionality besides implementing their own functionality), THEN I have an O/R mapper. And this can simply not be done with datasets. So, Any O/R mapper that does not do sobasically deals with no data driven inheritance, taking about the biggest advatage out. It means you are not an O/R mapper, but more an ORM-Mapper, mapping table structures intstead of object structures.
For me, in any nontrivial application, I would not want to ever deal with something that does not make data driven inheritance.
but if people learn how to use a dataset properly they may realize that it is a very effective data object that marginally undermines the benefits of your tool.
Just a question - have you ever developped al arger application? I mean something with let's say 150+ business objects mapping data from about 100+ tables, with inheritance hierarchies about a half a dozen levels deep (data driven)? In proper OO code?
If you have not - then what about you get the experience before degrading superior solutions?
I love the dataset. The dataset is a perfect example of how you can store relational data for a laye higher up. Sadly, I am not dealing with relational data - I deal with object oriented applications. There, using a dataset as replacement for a real object model is an attitude that - well, elt's say the moderators would not approove this post if I would tell what I seriously think about it.
Datasets are ´fine for what they do. Just - what they do is not what an application programmer wants.
We are adding, to the EntityBroker 3, a reporting interface. Guess what it will return - datasets. It makes perfect sense there, to get a tabular reporting form of "Data" - data has no logic attached, knows no inheritance. But my transactions continue to use a strong typed object model that knows data driven inheritance.
jdee
Member
57 Points
12 Posts
Re: Defending the DataSet: Agreeing to Disagree...
Jun 29, 2005 02:18 PM|LINK
One of my biggest dislikes about this forum is the vested interests that many posters display. Its becoming more and more like an advertising forum, where the answer to every question posted is 'buy an O/R mapper', usually posted by one of the 4 main vendors.
I've used O/R mappers, Datasets and EntLib in Enterprise applications all with great success. I've made my own judgment as to which is best in which scenario, I suggest that everybody does the same, and to not just think that O/R mappers are a panacea because someone else says so.
www.j-dee.com .NET weblog
Thanhq
Member
250 Points
50 Posts
Re: Defending the DataSet: Agreeing to Disagree...
Jun 29, 2005 07:38 PM|LINK
Very well said man.
Always keep an open mind and use the best tools available for the project. ADO.NET components, O/R mapper and EntLib are equally important tools built for very important purpose. Try not to listen to vendors or saleman unless they are soundly convincible. I hope that this forum would not turn into an advertising forum and I'm sure moderator of this forum would not want it to be. In the meantime, let's have fun, learn and share the best we have.
SeanSmith
Member
110 Points
22 Posts
Re: Defending the DataSet: Agreeing to Disagree...
Jun 29, 2005 11:35 PM|LINK
I'm not arguing for the DataSet. I'm just trying to offer an experienced counterpoint.
"Datasets do not handle lazy load scenarios well - you have to have all related items in the dataset."
This is only true if the DataRelation is set to enforce it's constraints.
No, it is true always. The DataSet has no support for lazy load operation in atransparent way. ALL data has to be manually loaded by the user. The contraint enforcement is a pain in the ass to deal with it, but you can turn it off. This, though, will not magically make data appear. DataSets are the dumpest form of data container you can have. They know onyl the absolute minumum they need to know, and have only the absolute minimum functionality. Now, this is fine - but it does not make all the other stuff magically appear.
You are mistaken. In the constructor for the DataRelation, the last argument is a boolean that specifies whether the relation should be enforced... If you create the relation and specify false, then you can still retrieve data using the data relation. You can specify computed columns using the relation. It is true that a DataSet doesn't load data automatically for you, but that really is not a data objects responsibility. IMHO it is a good thing that the data object only knows what they need to know.
I use ORMappers, but my ORMapper is used to generate separate data objects and business objects. Those data objects are commonly subclasses of the System.Data classes.
Then let me tell you your O/R mapper is a toy, as it does with a very high propability NOT deal with one of the most fundamental things: inheritance. If I ask for a list of ContentItems, and the list contains anything BUT content items (as the class is abstract, but has about 100 subclasses, most with additional data and all of them overriding common functionality besides implementing their own functionality), THEN I have an O/R mapper. And this can simply not be done with datasets. So, Any O/R mapper that does not do sobasically deals with no data driven inheritance, taking about the biggest advatage out. It means you are not an O/R mapper, but more an ORM-Mapper, mapping table structures intstead of object structures.
For me, in any nontrivial application, I would not want to ever deal with something that does not make data driven inheritance.
Nothing in my statements above should have led you to believe the ORMs I was speaking of did not support inheritence. As a matter of fact, they handle inheritance (both explicitly configured, and data schema defined inheritance) well. They use System.Data based objects ONLY in the data layer, not in the business layer. The business objects manipulate the data objects to reflect their business rules, they are not derived from data objects.
If your OR Mapper tightly couples your business objects and their inheritance tree to your data objects, then I could argue that your OR Mapper is a toy. However, I don't want to influence others with my speculation.
Just a question - have you ever developped al arger application? I mean something with let's say 150+ business objects mapping data from about 100+ tables, with inheritance hierarchies about a half a dozen levels deep (data driven)? In proper OO code?
If you have not - then what about you get the experience before degrading superior solutions?
150+ business objects and 100+ tables is a small to average sized application in my book. I don't want to get into a credentials contest however.
Applications do not have to be "relational" OR "object oriented". A well designed application is actually an interweaving of small, sefl consistent parts. The parts in the applications I have worked on in the past were comprised of data layer portions that were relational, and business layer portions that were object oriented. "Relational" AND "Object oriented".
I love the dataset. The dataset is a perfect example of how you can store relational data for a laye higher up. Sadly, I am not dealing with relational data - I deal with object oriented applications. There, using a dataset as replacement for a real object model is an attitude that - well, elt's say the moderators would not approove this post if I would tell what I seriously think about it.
Datasets are ´fine for what they do. Just - what they do is not what an application programmer wants.
We are adding, to the EntityBroker 3, a reporting interface. Guess what it will return - datasets. It makes perfect sense there, to get a tabular reporting form of "Data" - data has no logic attached, knows no inheritance. But my transactions continue to use a strong typed object model that knows data driven inheritance.
It is clear to me that we view the responsibilities of the different layers of an application differently. It sounds like your business layer and your data layer are more tightly coupled than I would like. In my experience business layer objects should manipulate data layer objects, but should not reflect their structure in anyway, unless it makes business sense for them to do so.
I agree with you that a mapping layer is required, I just don't believe that the mapping should be performed between the database and the data layer. I am willing to concede that optimal point to perform this mapping may fluctuate from application to application or problem domain to problem domain. I do not conceed that choosing to use System.Data based objects in your data layer has any real bearing on where that mapping is performed.
SeanSmith
Member
110 Points
22 Posts
Re: Defending the DataSet: Agreeing to Disagree...
Jun 30, 2005 01:57 AM|LINK
DgiPL
Member
100 Points
24 Posts
Re: Defending the DataSet: Agreeing to Disagree...
Jun 30, 2005 07:09 AM|LINK
Holy words. Amen.
Darek
FransBouma
Participant
1509 Points
312 Posts
Re: Defending the DataSet: Agreeing to Disagree...
Jun 30, 2005 04:06 PM|LINK
and
The sad thing is though that some anti-O/R mapper people play the 'You're biased!!' card when they don't agree with what an O/R mapper person has to say.
Also, the average developer here hasn't spend 3+ years full time (that's 5-7 days a week, 8+hours a day) on data-access and O/R mapping. Most O/R mapper vendors here have. They have waded through almost all problems data-access code will run into and more, far more than most of the people here ever will run into.
Needless to say, these people know what they're talking about.
The people who for example think I post here just to be the salesman, have no clue whatsoever and frankly aren't worth a second of my time, because most O/R mapper vendors here, including myself, aren't posting here to increase sales, we're posting here because we have the knowledge others ask for, as it's our day to day core topic of interest: solving the data-access problem, and so we give that knowledge to you.
Also, this forum is like this for a couple of years now, so I don't think it will fall apart as an advertising forum.
I do get a little bit tired though that O/R mapper vendors always have to defend their own opinion against bias and "you're advertising your own stuff!"-kinda crap.
For example, I never posted "You should buy the O/R mapper <insert brand here>"!!. It's acquisations like the one posted by JDee which make it more and more tiresome to discuss data-access related problems without having to deal with "You're biased", holy houses or other sillyness, instead of discussing the real matter and the real point.
If your argument is solely based on the fact that O/R mapper-oriented advice is biased and therefore should be ignored, realize that this forum isn't helped by that kind of attitude and neither are the ones asking a question or starting the discussion.
I mean, look at this discussion, it starts to look like a stored procedure vs. dyn. SQL discussion almost instantly. "AMD is better!!" "No!! nVidia!!"
...
LLBLGen Pro website: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
SeanSmith
Member
110 Points
22 Posts
Re: Defending the DataSet: Agreeing to Disagree...
Jun 30, 2005 06:40 PM|LINK
I wasn't trying to turn this discussion into a DataSet vs OR Mapper discussion. On the contrary, I was trying to convey that they are not opposed to one another at all. It is great of you and the other ORM vendors to come here and share your knowledge with us, and these boards would not be so popular without you all. I was hoping to address some of the overgeneralized criticisms of the DataSet, because it would be a shame one of thoese less experienced developers here completely overlooked it due to opinions they read here.
jdee
Member
57 Points
12 Posts
Re: Defending the DataSet: Agreeing to Disagree...
Jun 30, 2005 06:58 PM|LINK
>>The sad thing is though that some anti-O/R mapper people play the 'You're biased!!' card when they don't agree with what an O/R >>mapper person has to say.
Where on earth did you get the idea that I'm anti O/R mapper?? For your info Frans, I'm a happy fully paid up customer of yours. Read my post again and next time don't just quote the parts that suit your argument. Quote the part that says I'm fully aware of the advantages and disadvantages of ALL data access methodologies and that I choose the best one on a per project basis too.
>>For example, I never posted "You should buy the O/R mapper <insert brand here>"!!.
>>The people who for example think I post here just to be the salesman,
Ok, fair comment, but lets not be naive, we ALL know vendors who DO.with.tiresome...zzzz...crass....snore...regularity.....
>>Needless to say, these people know what they're talking about.
What? 100%? All the time? I should believe without question? Look at Sean's reply. I've done my own tests and drawn my own conclusions.
>>It's acquisations like the one posted by JDee which make it more and more tiresome to discuss data-access related problems without >>having to deal with "You're biased",
touche' - count the amount of 'You're biased' posts, and then count the amount of 'buy an O/R mapper' posts and you'll really see who is tired..... sprocs, ad-hoc sql, datasets, doing away with objects alltogether and writing strictly procedural code - they all have their uses, advantages and disadvantages.
Anyway, if anyone is interested I'll finish up with a quote from The Pragmatic Programmer by Andrew Hunt & David Thomas:
"Critically Analyze What You Read and Hear. Don't be swayed by vendors, media hype, or dogma. Analyze information in terms of you and your project."
www.j-dee.com .NET weblog