where should datasets reside in a n-tier (multi layered) architecture?

Question

We are currently havin a discussion if dataset should go in the data or business layer?

My friend thinks all ADO.NET components should go in data layer. For me this does not seem right for the followin reasons:

• If you create a fat Data Layer Client, it will be much more difficult to for example migrate everything to a different data source.
• You cant have bound controls unless you skip the business layer logic.

I think that datasets and datatables should be in the business logic since they are generic to all data providers. The data layer should have a Provider Factory for instantiating the right provider's objects (Connection, DataAdapters, Transactions,DataReaders, etc). For me this is the way to go for the following reasons:

• Migrating to a different data layer is as easy as it gets.
• You can bind your controls to rich business objects

Can some n-tier guru help us clear out wich way to go? Thanks in advance

Answer 1

In my opinion, don't use DataSet at all. Don't even use typed DataSet. These are old constructs created before LINQ. Skip right over ancient history, and get into the present tense: use LINQ to Entities and the Entity Framework (EF). The two are closely related but not the same.

Don't expose an EF entity across a service boundary. Unfortunately Microsoft chose to expose implementation details when serializing an entity. Other than that, use EF and have a lot more fun than you would have had with DataSet.

Answer 2

A typical approach is to expose an aggregate root (like Customer) repository interface in your business logic layer/domain, and implement the concrete repositories in your data access layer/infrastructure.

Answer 3

I would have to agreee about not using dataSets at all. One of the applications that I worked on there were DataSets in both Data layer and in the Application layer. The DataLayer DataSets matched the DataBase where the Application layer datasets denormalized the information to make it more consumable to the frontend.

Answer 4

Well, isolating data access is not new : we does it 15 years ago (yes, 15 years ago !).

I have worked in a lot of places and I saw a lot of isolated data layers.

But I never -- ever ! -- seen a data source being replaced !

Yes, I saw it twice : and twice, we also replace the oudated data layer and all the toping software...

My answer is pretty simple : unless you are working for shelve softwares, you can isolate as much as you want the data layer, you will do it for nothing.

For nothing because nobody will change SQL Server or Oracle just for changing. And for nothing because the day someone will do it, either they will also rewrite their softwares or they will make shure that the product they are buying is compatible to the product they are lefting.

In my books, any data layer is stupid.

If you do not agree with it, just tell me when in your life this layer save $$$ to someone...

Answer 5

The fundamental issue I have with DataSets is that their structures are an exact mirror of the database schema.

If you expose the DataSet to the actual page rendering code, you are effectively exposing the database schema (the ultimate backend of the product) to the presentation layer. Now the obvious problem can happen: later down the track you will want to restructure the underlying data schema, and because of the design you will need to apply changes to all of the other layers in the system. It's a prime example of encapsulation not being used when it really should be.

If you are going to use DataSets at all, keep the DataSets buried right down in the data access layer, and expose a conceptual set of business objects to the presentation layer. The set of business objects you expose should be designed according to good object oriented principals, which is completely different to good relational database design principals.