I've recently recieved an enail regarding my article about typed-datasets. It posed an interesting question as to when one would use typed datasets and on what types of projects. I'm posting it and my reply.

Hi Roy,

I subscribe to your RSS feed and have noticed that you seem to be a supporter of using strongly typed datasets in applications. If you wouldn't mind, I'd be grateful if you could share some of your thoughts on your position a bit further.

On my current project our technical lead has advocated the use of custom business entity objects instead that expose typed properties which internally contains a datatable. The custom entity class would also have other methods to get/set data plus know how to load data from the database and persist it back again.

One of the main arguments our lead is advocating is that the entities that contain the data we use in the application become smart entities that know how to handle their data, as opposed to the dataset which is just a container for data and which requires a separate class to handle calls against the database. Our lead also maintains that he has read in several newsgroups that typed datasets tend to be for “newbies” and that they are good for learning how to get started in .NET but have limited benefit for advanced application design.

Hi.

Typed Datasets are not the answer to everything.

Your boss may be right in this case. Typed datasets are mainly for use in small , simple projects, which require fast time-to-market with a database that changes rarely.

They are not a good replacement for a business layer in a complex application, since they are typed ,which has several disadvantages:

1) Any assembly that uses the typed datasets must have a reference to the assembly in which they reside.

Since typed datasets usually reside directly in the data-oriented layer, this would mean using typed datasets from you GUI would eliminate the decoupling between the GUI and the data layer, thus removing all abstractions needed.

2) They do not hold specific business-rules.

So in order to preserve ,say, a bank account balance in a certain minimum, you have 2 choices:

-Write the code inside the typed dataset class to handle this (cumbersome at best)

-Make the database tables contain these rules (which is pretty limited , and makes your data layer And Data holder hold business rules

3) Any changes to the database schema mean re-generation of the typed datasets, meaning re-referencing and compilation of all layers that reference it.(Plus any code changes you would make to the classes would be overwritten)

These 3 disadvantages give you a clear picture of what applications SHOULD use typed datasets:

1) They would have a maximum of 2-tier approach , meaning simple business rules or rules that are kept in the GUI

2) They should be small enough to be manageable when changes to requirements occur

As you can see, complex N-Tier Applications are better off with a solution other then typed datasets, or they would become unmanageable. The beauty of a business layer is that it abstracts the data layer into a logical entity, thus , if database changes occur or even if the database type itself changes, there should be no changes to the presentation tier, only to the data layer. The business layer would then go about retrieved the data needed and presenting it to the presentation layer how it sees fit.

Stateful business objects are not always the answer either

The Dataset object was specifically designed to be transported between layers.

Its only purpose is to contain data, and its schema. Thus you could have a data layer pass a dataset to the business layer which forwards it to the presentation layer, and no reference to the data layer should be created by the presentation layer. This allows you , instead of always returning large sets of stateful objects, to return datasets from logical objects in your business layer, making your business layer hold mainly objects that abstract you business rules and return results. It also saves you time and money that would be spent on reproducing logical relationships of the data in your database using custom classes.

Typed Datasets are NOT for newbies

It's a technology that allows creating fast time-to-market applications. It's use should be deliberated beforehand, but when applied correctly it can yield amazing results.

One more thing

Your Lead mentions that a Class is needed ABOVE the typed datasets in order to work with it. That is correct for abstracting the way the business logics behaves. You would call an object's method, and internally it uses the typed dataset to make database changes. This approach can be used in a 3-tier application to simplify coding against the database for the data layer objects. In this design you create a logical object for each table, and this object ,internally, uses a typed dataset to manage the table. This might be overkill in some situations, and all of the drawbacks I mention above apply here as well. But is you manage to keep the typed dataset to be used solely by the data layer or business object and not by the GUI ,you might be able to create easier to manage database operations.

Regards,