¿Dónde deberían residir los conjuntos de datos en una arquitectura de n niveles (múltiples capas)?

Question

¿Estamos discutiendo si el conjunto de datos debe ir en la capa de datos o de negocios?

Mi amigo piensa que todos los componentes de ADO.NET deberían ir en la capa de datos. Para mí, esto no parece correcto por las siguientes razones:

• Si crea un cliente de capa de datos grueso, será mucho más difícil, por ejemplo, migrar todo a una fuente de datos diferente.
• No puede tener controles vinculados a menos que omita la lógica de la capa empresarial.

Creo que los conjuntos de datos y las tablas de datos deberían estar en la lógica empresarial, ya que son genéricos para todos los proveedores de datos. La capa de datos debe tener una fábrica de proveedores para crear instancias de los objetos del proveedor correcto (conexión, adaptadores de datos, transacciones, lectores de datos, etc.). Para mí, este es el camino a seguir por las siguientes razones:

• Migrar a una capa de datos diferente es tan fácil como parece.
• Puede vincular sus controles a objetos comerciales ricos

¿Puede algún gurú de n niveles ayudarnos a aclarar qué camino tomar? Gracias de antemano

Answer 1

Donde estoy, devolvemos conjuntos de datos, tablas de datos, líneas de datos y lectores de datos de la capa de datos a la capa empresarial.

La razón es que estos tipos no son específicos del sabor db. Ya sea que use mysql, access, sql server, oracle o cualquier conjunto de datos que sea un conjunto de datos y, por lo tanto, está bien regresar de una capa de datos de nivel raíz.

Una capa empresarial toma estos datos en bruto y los convierte en objetos comerciales fuertemente tipados, aplicando las reglas comerciales necesarias, para entregar a la capa de presentación.

---

Editar: mientras reviso algún código, no usamos mucho un conjunto de datos completo. Se trata principalmente de tablas de datos y lectores de datos.

Answer 2

En mi opinión, no use DataSet en absoluto. Ni siquiera use DataSet escrito. Estas son construcciones antiguas creadas antes de LINQ. Salta a la derecha sobre la historia antigua y entra en el tiempo presente: usa LINQ to Entities y Entity Framework (EF). Los dos están estrechamente relacionados pero no son lo mismo.

No exponga una entidad EF a través de un límite de servicio. Lamentablemente, Microsoft decidió exponer los detalles de implementación al serializar una entidad. Aparte de eso, usa EF y diviértete mucho más de lo que hubieras tenido con DataSet.

Answer 3

Bueno, aislar el acceso a datos no es nuevo: lo hicimos hace 15 años (¡sí, hace 15 años!).

He trabajado en muchos lugares y vi muchas capas de datos aisladas.

¡Pero nunca, nunca! - ¡se ha reemplazado una fuente de datos!

Sí, lo vi dos veces: y dos veces, también reemplazamos la capa de datos desactualizada y todo el software de toping ...

Mi respuesta es bastante simple: a menos que esté trabajando para softwares de estanterías, puede aislar tanto como desee la capa de datos, no lo hará por nada.

Para nada porque nadie cambiará SQL Server u Oracle solo por cambiar. Y para nada, porque el día que alguien lo haga, o también reescribirán sus softwares o asegurarán que el producto que están comprando es compatible con el producto que están dejando.

En mis libros, cualquier capa de datos es estúpida.

Si no está de acuerdo con esto, solo dígame cuándo en su vida esta capa le ahorrará $$$ a alguien ...

Answer 4

Un enfoque típico es exponer una interfaz de repositorio raíz agregada (como el Cliente) en su capa / dominio de lógica de negocios, e implementar los repositorios concretos en su capa / infraestructura de acceso a datos.

Answer 5

El problema fundamental que tengo con DataSets es que sus estructuras son un espejo exacto del esquema de la base de datos.

Si expone el DataSet al código de representación de página real, está exponiendo efectivamente el esquema de la base de datos (el último back-end del producto) a la capa de presentación. Ahora puede suceder el problema obvio: más adelante en el camino querrá reestructurar el esquema de datos subyacente y, debido al diseño, deberá aplicar cambios a todas las otras capas del sistema. Es un excelente ejemplo de encapsulación que no se usa cuando realmente debería ser.

Si va a utilizar DataSets en absoluto, mantenga los DataSets enterrados directamente en la capa de acceso a datos y exponga un conjunto conceptual de objetos comerciales a la capa de presentación. El conjunto de objetos de negocio que exponga debe diseñarse de acuerdo con principios bien orientados a objetos, que es completamente diferente a los principios de diseño de bases de datos relacionales.

Answer 6

Tendría que estar de acuerdo en no usar dataSets en absoluto. Una de las aplicaciones en las que trabajé allí fue DataSets tanto en la capa de datos como en la capa de aplicación. Los conjuntos de datos DataLayer coincidieron con la base de datos donde los conjuntos de datos de la capa de aplicación desnormalizaron la información para hacerla más consumible para la interfaz.