Search code examples
.netarchitecturedatasetn-tier-architecture

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

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?

Solution

  • 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.