Onde os conjuntos de dados devem residir em uma arquitetura N-Tier (várias camadas)?

Question

Atualmente, estamos tendo uma discussão se o conjunto de dados deve ir na camada de dados ou negócios?

Meu amigo acha que todos os componentes do ADO.NET devem entrar na camada de dados. Para mim, isso não parece certo pelas seguintes razões:

• Se você criar um cliente de camada de dados gordos, será muito mais difícil, por exemplo, migrar tudo para uma fonte de dados diferente.
• Você não pode ter controles vinculados, a menos que pule a lógica da camada de negócios.

Eu acho que conjuntos de dados e dados de dados devem estar na lógica de negócios, pois são genéricos para todos os provedores de dados. A camada de dados deve ter uma fábrica de provedores para instanciar os objetos do provedor correto (conexão, dataadapters, transações, DataReaders etc.). Para mim, este é o caminho a seguir pelos seguintes motivos:

• Migrar para uma camada de dados diferente é o mais fácil possível.
• Você pode vincular seus controles a objetos de negócios ricos

Algum guru da N-Tier pode nos ajudar a limpar o caminho a percorrer? desde já, obrigado

Answer 1

Onde estou, retornamos conjuntos de dados, dados, datarows e datareaders da camada de dados para a camada de negócios.

A lógica é que esses tipos não são específicos de sabor de banco de dados. Se você usa MySQL, Access, SQL Server, Oracle ou qualquer que seja um conjunto de dados, seja um conjunto de dados e, portanto, é bom retornar de uma camada de dados de nível raiz.

Uma camada de negócios pega esses dados brutos e o transforma em objetos de negócios fortemente tipados-aplicando todas as regras de negócios necessárias-para entregar a camada de apresentação.

---

Editar: Enquanto olho em algum código, não usamos muito um conjunto de dados completo. São principalmente dados de dados e DataReaders.

Answer 2

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 3

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 4

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