Architecture

Re: Defending the DataSet: Agreeing to Disagree...

Qnnn — Fri, 01 Jul 2005 13:29:51 GMT

Seems like you had your architecture and models already done and then you tried mappers and datasets. Well... this kind of decisions should be made in earlier stages. Also it seems like you don't get all the context of mappers as I don't see here any sensible argumentation. Maybe you can describe your experiments and experiences?

(no flame - I'm using both of them - mappers and datasets).

Re: Defending the DataSet: Agreeing to Disagree...

jd2356 — Fri, 01 Jul 2005 12:56:02 GMT

Here is our two cents...for what it's worth
Currently we are developing what I would call a fairly large enterprise wide application that ties together all of our business groups, clients, and suppliers. We started this project 1 year ago and development is going along at a pretty good clip. Now here are the stats....remember also that we are designing and building everything from the ground up.
1: We have 8 seperate databases to support internal company data - total of almost 460 tables in 3rd normal form
2: We have a standard structure for each seperate customer database, which is expanded to meet the special needs of the client - base design is about 30 tables in 3rd normal form, currently we have 11 customer databases installed
3: 220 Business Objects
4: 10 Postal Objects
5: 15 Security Objects
6: 10 Web Applications with over 120 aspx pages and 200 user defined web controls that are reused
7: 12 Windows Services
8: 10 Web Services
9: Internal Developed Business Event Message System
10: Internal Developed Workflow Engine
11: Internal Developed Business Rules Engine

And growing...and guess what, poor us, we don't have an OR mapper and don't need one, we tried a couple, they may be good for a small single purpose application, but once you get into larger systems they just get in the way....but, like I said, this is just our two cents

Re: Defending the DataSet: Agreeing to Disagree...

GirlWithRedGlasses — Fri, 01 Jul 2005 10:38:57 GMT

mynameismud wrote:
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.

And in saying this, you have added another one.

Re: Defending the DataSet: Agreeing to Disagree...

mynameismud — Fri, 01 Jul 2005 07:46:24 GMT

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.

Re: Defending the DataSet: Agreeing to Disagree...

Caddre — Fri, 01 Jul 2005 01:07:14 GMT

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.

Re: Defending the DataSet: Agreeing to Disagree...

Thanhq — Thu, 30 Jun 2005 23:04:06 GMT

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

Re: Defending the DataSet: Agreeing to Disagree...

FransBouma — Thu, 30 Jun 2005 21:18:44 GMT

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.

Re: Defending the DataSet: Agreeing to Disagree...

FransBouma — Thu, 30 Jun 2005 21:09:45 GMT

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.

Re: Defending the DataSet: Agreeing to Disagree...

jdee — Thu, 30 Jun 2005 18:58:54 GMT

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

Re: Defending the DataSet: Agreeing to Disagree...

SeanSmith — Thu, 30 Jun 2005 18:40:48 GMT

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.

Re: Defending the DataSet: Agreeing to Disagree...

FransBouma — Thu, 30 Jun 2005 16:06:45 GMT

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

...

Re: Defending the DataSet: Agreeing to Disagree...

DgiPL — Thu, 30 Jun 2005 07:09:49 GMT

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.

Re: Defending the DataSet: Agreeing to Disagree...

SeanSmith — Thu, 30 Jun 2005 01:57:24 GMT

Thanks for compliments jdee and Thanhq.

Re: Defending the DataSet: Agreeing to Disagree...

SeanSmith — Wed, 29 Jun 2005 23:35:11 GMT

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.

Re: Defending the DataSet: Agreeing to Disagree...

Thanhq — Wed, 29 Jun 2005 19:38:29 GMT

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.