数据集应该位于 n 层（多层）架构中的什么位置？

Question

We are currently having 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 following 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 can't 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 which way to go?

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

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 3

Where I'm at we return datasets, datatables, datarows, and datareaders from the data layer to the business layer.

The rationale is that these types are not db-flavor-specific. Whether you use mysql, access, sql server, oracle, or whatever a dataset is a dataset, and therefore okay to return from a root level data layer.

A business layer then takes this raw data and turns it into strongly-typed business objects — applying any necessary business rules — to hand to the presentation layer.

---

Edit: As I look through some code, we don't use a full dataset much. It's mostly datatables and datareaders.

Answer 4

一种典型的方法是在您的业务逻辑层/域中公开一个聚合根（如客户）存储库接口，并在您的数据访问层/基础设施中实现具体的存储库。

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.

Answer 6

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.