Where should the data be located in an n-tier (tiered) architecture?

Question

We are currently discussing whether the data set should go at the data or business level?

My friend believes that all ADO.NET components should go in the data layer. For me, this does not seem right for the following reasons:

• If you create a thick data layer client, it will be much more difficult, for example, to transfer everything to another data source.
• You have no attached controls unless you miss the business-level logic.

I think that datasets and data should be in business logic, as they are common to all data providers. At the data level, there must be a Factory provider to create provider objects (Connection, DataAdapters, Transactions, DataReaders, etc.). For me, this is a way to go for the following reasons:

• Moving to another level of data is as easy as it is.
• You can associate your controls with rich business objects.

Can any n-tier guru help us clarify which way? thanks in advance

Answer 1

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

The rationale is that these types are not specific to the db taste. Regardless of whether you use mysql, access, sql server, oracle or any data set, it is a data set, and therefore you can return from the data level at the root level.

Then the business layer takes this raw data and turns it into strongly typed business objects — applying any necessary business rules; for submission to presentation level.

---

Edit:. When I look at some code, we do not use the full data set. These are mainly datatables and datareaders.

Answer 2

In my opinion, do not use a DataSet at all. Do not even use typed DataSets. These are old designs created before LINQ. Skip right to ancient history and go now: use LINQ to Entities and Entity Framework (EF). The two are closely related, but not the same.

Do not expose the EF to service boundaries. Unfortunately, Microsoft decided to expose implementation details when serializing the entity. In addition, use EF and get a lot more fun than you have with the DataSet.

Answer 3

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

I have worked in many places, and I have seen many isolated data layers.

But I never - never! - I saw the replaced data source!

Yes, I have seen this twice: and twice, we also replace the level of ovudation data and all the topping software ...

My answer is quite simple: if you do not work with the software for the shelf, you can select as much as you want a data layer, you will do it in vain.

For nothing, because no one will change SQL Server or Oracle just for a change. And for no reason, because that day when someone does this, either they will also rewrite their software, or they will make the product that they buy compatible with the product that they leave.

In my books, any data layer is stupid.

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

Answer 4

A typical approach is to expose the aggregate root repository interface (e.g., Customer) in your business logic level / domain and implement specific repositories at your data / infrastructure access level.

Answer 5

The main problem I encounter with DataSets is that their structures are an exact mirror of the database schema.

If you expose a DataSet for the actual page rendering code, you effectively show the database schema (the final backend of the product) at the presentation level. Now the obvious problem may occur: later on the track, you will want to restructure the basic data scheme, and because of the design, you will need to apply the changes to all other levels in the system. This is a prime example of encapsulation, which is not used when it really should be.

If you intend to use the DataSet at all, keep the DataSets similar to the right level of access at the data access level and expose a conceptual set of business objects to the presentation level. The set of business objects that you publish must be designed in accordance with good object-oriented principles, which is completely different from good relational databases.

Answer 6

I have to agree that I do not use dataSets at all. One of the applications I worked on was DataSets, both at the data level and at the application level. DataLayer DataSet mapped DataBase, where application-level datasets denormalized information to make it more accessible to the external interface.