datasets or custom business objects?

[devbanana]

Datasets, as in the kind you can generate from Visual Studio 2005, seem pretty useful, but i thought I read something discouraging their use. Why so, if this is correct? Is it generally prefered to use a dataset strongly typed object, or a business object?

[pufa]

Designing Data Tier Components and Passing Data Through Tiers
http://msdn.microsoft.com/library/de...tml/BOAGag.asp

Also read the best practices topic there is a nice discution about the subject.

[CompiledMonkey]

I like to use custom business objects.

[devbanana]

But, why? I'm asking for specifics here. What is wrong with the strongly typed dataset objects? Please give me a bit more specifics.

Thanks.

[Benjymouse]

Good question.

To be sure there are advantages and disadvantages with both approaches. And things have changed with ADO.NET 2.0. At least for me this has meant that the typed dataset is a viable solution in many more situations than before.

What am I talking about?

1) The dataset has been greatly optimized, especially for larger volumes.

2) The dataset now has a binary serialization format, making it much more effective when storing in session or even viewstate.

3) The typed dataset now take advantage of the partial classes. This means that I can "extend" the row classes of the typed dataset. I use extend in quotes here, because it is actually much more like a mixin. The end result is that I *can* define my own properties, methods etc. directly on the row classes *and* have the rest of the code recognize this without any typecasts.

At the same time, the dataset has many advantages over a home grown custom business objects implemented using classes and collections. Consider

1) Searching, filtering, sorting. I could certainly do with a more elegant expression language (LINQ?). I really miss parameterized queries/filtering. Nevertheless, querying/sorting a dataset is often comparatively simpler than doing the same with a graph of objects. And for all but the smallest data samples, it will often be faster too.

2) Easily extracting/isolating changes. Often you will find it hard to implement your business objects in such a way that they can tell you *what* has changed. You typically design the BOs to be a view of the "current" situation only.

3) Cascading changes are handled automatically by a dataset. The same task would require specific code for a class based BO model. This can certainly make things harder when you synchronize the BOs with the database.

I never use custom BOs anymore. Too clunky, too much work, too much pain. For advanced projects with large object models i go with a real ORM. For smaller/midsize models I use a typed dataset, in effect building my BOs with partial classes.

[devbanana]

Quite interesting. Was there not something in the best practices thread though that discouraged the use of datasets? or am I refering to something different? Or has this opinion changed.

I agree it seems quite a lot easier to use these strongly typed datasets. I wonder though if it'd get more complicated, or perhaps instead easier? when relationships get more complicated between tables. For instance, foreign keys, etc.

Excuse my ignorance, but what do you mean by "ORM"? Only possible thing I can think of is "object oriented model"? Anyway, how do you handle these types of things in larger projects?

Thanks for the very helpful reply!

[wwb_99]

I still have not learned to love the dataset, even in 2.0. Though I do admit to using them alot more for data access. But I still am squarely in the "build database unaware object layer and custom data access layer" school of thought.

A few reasons:

1) Partial classes let you extend datasets, but you still cannot enforce constraints on fields when setting properties.
2) Datasets as base business objects imply you will always be communicating with a database as the datastore. I would note that in many cases one's data store is a remote service (.NET remoting/web service) which does not transtlate into datasets.

While they have been vastly improved, and I am warming up to using them in small projects and for data access, I still like to separate out into a pure object tier and a pure persistance teir (or teirs).

ORM is object relational mapper. Such as NHibernate or NetTiers. They can be pretty slick, or they can suck, depending on how fancy the database is.

PS: Forgot one final important reason for custom BOs: testing. If you are doing unit testing, you really need to have business objects that can exist outside of the database so that one can test the logical functionality separate from integration tests using the data tier.

[devbanana]

Originally Posted by wwb_99

I still have not learned to love the dataset, even in 2.0. Though I do admit to using them alot more for data access. But I still am squarely in the "build database unaware object layer and custom data access layer" school of thought.

A few reasons:

1) Partial classes let you extend datasets, but you still cannot enforce constraints on fields when setting properties.
2) Datasets as base business objects imply you will always be communicating with a database as the datastore. I would note that in many cases one's data store is a remote service (.NET remoting/web service) which does not transtlate into datasets.

While they have been vastly improved, and I am warming up to using them in small projects and for data access, I still like to separate out into a pure object tier and a pure persistance teir (or teirs).

ORM is object relational mapper. Such as NHibernate or NetTiers. They can be pretty slick, or they can suck, depending on how fancy the database is.

PS: Forgot one final important reason for custom BOs: testing. If you are doing unit testing, you really need to have business objects that can exist outside of the database so that one can test the logical functionality separate from integration tests using the data tier.

interesting post. what do you mean by: "pure
object tier and a pure persistance teir"

Now I'll have to do a bit of research to see which seems the best...and how to use each

[wwb_99]

Pure Object Tier==object tier that is unaware of the underlying data storage. It just holds data and enforces business rules.

Pure Persistance Tier==data tier that takes the objects described above and handles CRUD.

[devbanana]

Hmm, ok I seem to agree, but I also see the advantages of using datasets or strongly typed datasets.

The thing with custom business entities is you need to manually take care of things like, serialization, searching, sorting, allowing the entity to be part of a collection, etc. That's the only disadvantage I can see.

P.S. Just to clarify, do you basically mean a DALC that takes and returns some kind of custom business entity? For example:

Product someProduct = Products.Get(7);
someProduct.Name = 'IBM';
Products.Save(someProduct);

[wwb_99]

Pretty close, but I tend to completely separate the persistance bit from the object. So you would see something more like:

ProductDataManager pdm=(ProductDataManager)App.GetDataManager(typeof(Product));
Product p=pdm.Load(8);
p.Name="IBM";
pdm.Save(p);

Searching when everything is abstracted like this is a bit trickier, and I will admit there is no perfect solution. But I am working on it.

[devbanana]

So it looks like what I had, except you have a factory method return the appropriate object? I actually like it. What is the total responsibility of the App object, though?

Indeed, searching etc seems difficult, but I'm going to see the best way to resolve that. I'd probably make a custom collection class; for instance, for the above example, ProductCollection.

// Get the first page of 15 products
ProductCollection pc = pdm.GetProducts(1, 10, ProductSort.Name, ProductSortType.Ascending);
for (Product p in pc)
{
    // Do stuff here...
}

Though I'm not sure if sorting would be a responsibility of the collection or the data manager.

[Benjymouse]

DataSets need not communicate with any database. They are simply a relational oriented local store. TableAdapters is what is ties into a database. The DataSet can equally well expose data retrieved from a webservice. In fact, the close relation between a DS and xml makes it really simple to do this.

The xml serialization also what makes it possible to test a domain model based on a DS. No need to synch with a database, just load the testing set from a xml file which resides along with the test under source control.

Sure, DSs do have shortcomings, but for a number of situations I find them quite useful. And they definately support a RAD style development, esp. in 2.0.

A custom BO model also has shortcomings. Typically it's hard to make queries against a BO model, especially when the queries does not follow parent-child relationships.

I'm not arguing against custom BOs. But you should not dismiss the features that comes with DSs either.

Galo, you may want to check out Microsoft Enterprise Library (downloadable from MSDN). It adresses issues like data access, logging, testing etc. on a higher level than the .NET Framework itself.

[devbanana]

Benjymouse,

As I said, i do see the benefits of both, so I'm just going to watch what you and wwb_99 say about both sides. I'm really not sure how I feel about it yet.

And I believe you meant devbanana, not galo

Anyway, this enterprise Library looks quite interesting. I think I'll see what's in it. Thanks.

[devbanana]

About wwb_99's comment that you can't do validation in strongly typed datasets, this appears to be untrue. See the example here.

Quite interesting...

[wwb_99]

Good catch, devbanana. Typed DataSets are looking slightly more attractive now. I would argue that creating the DataSet from xml is still an integration test with a new entity rather than an actual unit test, but no need to get into the semantics of test driven development here.

Note that I probably would have a much different attitude if I were in a different line of business. Where I sit now I have to live with whatever I create/manage creation of for a good long time. So I tend to go for very well crafted, maintainable solutions rather than relying on RAD tools. Especially after having been bitten by the RAD bug a few times.

The enterprise library is very, very slick. I use it for most non-trivial things, and use a much ligher weight database access library for the more trivial things. Version 2.0 is much improved, particularly in the "you don't need root access to run this anymore" category.

As for the app variable, it is a reference to the general application manager which handles things like configuration and factories for other things. It is a stateless (aside from having loaded configs) singleton.

Regarding searching, I have tended towards developing custom search parameter objects which can be translated into appropriate queries by the datasource. The advantage to this is you can use the same search parameter object for the database driven side and the XML driven side.

[devbanana]

Yeah, they look pretty good. I'll do a bit of playing around with it and see how it goes.

Well, I quite like RAD development. I've messed with tools before that claimed to allow for RAD development, but they more slowed me down than anything. Hopefully I can actually get somewhere using this.

This enterprise library, when I try to open the documentation from the start menu, it tells me the document explorer can't be opened because the file is invalid.

OK, I know it is prefered to use stored procedures, but what should be included in these? For instance, in my application I want to track the number of users online, including both members and guests. So, I wanted to check if the current user is already in the table, and if so, then do an update, otherwise, do an insert. I was going to stick all that into one procedure; would this be the best thing to do? Then the dataset could just call this procedure, passing the current user's information.

anyway, regarding typed datasets vs. custom business objects. I'd say my feeling right now is that typed datasets are quite convenient, but it seems more elligant to use custom business entities. Not exactly sure why I feel that, though.

Oh by the way, with typed datasets, can you specify which namespace it is put into? Or how do you know where it is, as far as namespaces are concerned?

Bleh, a million and a half questions...oh well