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.

Well said that man.

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.

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.

 

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.

Thanks for compliments jdee and Thanhq.

Thanhq wrote:

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.

Holy words. Amen.

JDee and Thanhq, you wrote:

jdee wrote:

Well said that man. 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 wrote:

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!!"

...

Hello Frans,

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."

jdee wrote:

>>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.

It was a generic remark about anti-O/R mapper people playing the you're biased card. :) Not necessarily towards you personally, as personal attacks are rather silly, I wanted to make a general remark about a topic you started IMHO. If I got a euro for every time someone told me I'm biased when it comes to something related to data-access... :)

>>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.....

Even if they do, why bother? It's common knowledge that on forums like these, if you just reply to every question with "buy my product, it will solve your problem", you will be ignored pretty quickly. ;)

>>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.

In general, yes they do know what they're talking about. The thing is: without proper knowledge you won't be able to develop a proper O/R mapper which is worth mentioning. (let's not get into the criteria handled by some people if something is a toy or not ;) )

>>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.

Of course they have. What made me post my posting was that I found it rather odd that there were 2 postings right after eachother about bias, vendors being salesmen and the fear that this forum becomes an ad-agency. I found it odd because there wasn't a reason IMHO for that posting. A topic was discussed, and like it or not, when 'datasets' and 'advantages' are at the core of the topic at hand, the pro/con discussion about O/R mappers isn't far away.

SeanSmith wrote:

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.

Agreed, you were more or less down playing some Dataset myths. I can relate to that and appreciate your effort :) The less myths in IT, the better :)

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 dataset definitely has its place, I use it too, well the datatable but that's the important part of a dataset, for readonly lists.

Discussions about datasets and its pro/cons however have the tendency to fall into 'object vs dataset' discussions and what's better. This of course isn't an empirical provable point, it depends on how you look at things: do you like to work with sql, resultsets and the like or do you like to focus on the entity. These are fundamental differences, which really make a person take one side or the other and which is better... it depends on the context in which they're used. A person who likes to work with resultsets and raw SQL, will feel at home with datasets, though not with objects, and vice versa, a persom who focusses on entities and not on resultsets and raw SQL, will miss something with a dataset and not with objects.

That aside, myths like 'this is slow' 'that isn't useable in context ABC' etc. should be set straight, no matter what you use as hte startpoint of your POV on the data-access problem.

FransBouma wrote:

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.

I'm not anti-O/R mapper or anti-ADO.NET components either. I always try to look at what's the best possible way to solve problems whether it's an O/R mapper or something else. I always keep an open mind and try to be fair to all tools in any way I can as most members of this forum do. I do believe that there are some vendors using this forum promoting their products in a not so fair way. This is where I agree to disagree.

I have read many of your posts and learned a lot from you. So let me take this opportunity to say thank you for your contribution and it's highly appreciated(at least by me).

  

FransBouma wrote:

Discussions about datasets and its pro/cons however have the tendency to fall into 'object vs dataset' discussions and what's better. This of course isn't an empirical provable point, it depends on how you look at things: do you like to work with sql, resultsets and the like or do you like to focus on the entity. These are fundamental differences, which really make a person take one side or the other and which is better... it depends on the context in which they're used. A person who likes to work with resultsets and raw SQL, will feel at home with datasets, though not with objects, and vice versa, a persom who focusses on entities and not on resultsets and raw SQL, will miss something with a dataset and not with objects.

Entity is Peter Chen 1976 ERD(entity relationship diagram) so a data person is also entity focused. Objects only person needs a commercial O/R mapper and object relational person can use Nhibernate and both  types of developer's use this forum. I need to know why Nhibernate and Nvelocity are used in one project because in there are the structural  reasons object developers need commercial O/R mapper.  And I was reading EA when there are only few chapters online in 2001.  And there is no Domain design here so I am going to have a blast with DRI(declarative referential integrity) SET NULL and index Column include making every column NULLABLE.

Prefetch is TDS(tabular data stream) available from any good third party driver again still just data.

You are forgetting the main pro of the dataset - this little API can produce endless forum threads with developers making meaningless and ultra-wide statements of global application architecture.