architecture - pasar datos en una aplicación ntier

domain-driven-design n-tier-architecture

Question

¿Cómo se pasan los datos a las capas en una aplicación de n niveles? He trazado tres métodos diferentes.

A) generic .net objects tablas de datos genéricos, Hashtables, datasets genéricos, cadenas, ints, etc ... luego usa los conjuntos de datos para llenar los objetos de negocios que se envían a la capa de UI.

texto alternativo http://img11.imageshack.us/img11/460/generic.png

http://dabbleboard.com/draw?b=eiu165&i=26&c=54eef6f1ac01f03c85919518f4a24e798e57e133

Pro- No se necesitan capas adicionales Con- Tiene que trabajar con conjuntos de datos genéricos y tablas en la capa de negocios

B) usando una capa de entidades a la que las otras capas harían referencia. Esta capa contendría conjuntos de datos fuertemente tipados o objetos simples de C antiguos. Los objetos serían principalmente datos de contenedores y muy poca lógica. estos serían los mismos objetos enviados a la capa UI.

texto alternativo http://img8.imageshack.us/img8/6454/entities.png

http://dabbleboard.com/draw?b=eiu165&i=6&c=d0c2b346894a96b12bd3867f630e474a2af098fa

Programar con las mismas clases en todas las capas Agregar una referencia a entities.dll a todas las capas

C) usar objetos de transferencia de datos (solo objetos conatiner) definidos en la capa de DataAccess. luego usar esos objetos para llenar los objetos comerciales que se envían a la capa UI.

texto alternativo http://img43.imageshack.us/img43/1236/transferp.png

http://dabbleboard.com/draw?b=eiu165&i=27&c=f886efa3f9d5eb4b45ddb02361c79cdcdaec0a9b

Pro- la capa de negocios no tendría que funcionar con clases genéricas. Contar con dos tipos de objetos y tendría que hidratar los objetos de negocio con los objetos de transferencia

Tuvimos una discusión en el trabajo y queríamos ver qué pensaba la comunidad. También agregué un enlace al tablero. por favor copie y cree en lugar de editar.
Gracias

Answer 1

Gran pregunta: como siempre, la respuesta debe ser "depende".

En cuanto al tipo de aplicación, y si realmente es necesario tener objetos comerciales (Entidades), en lugar de objetos de transferencia (es decir, objetos comerciales simplificados que corresponden más a entidades de bases de datos).

Tradicionalmente, habría argumentado que siempre se necesitan conjuntos de datos genéricos (o tablas de datos), puramente por razones de rendimiento. Cada vez que hay una necesidad de trabajar con, mostrar o manipular conjuntos más grandes, la forma tradicional estricta OO de instanciar grandes cantidades de objetos comerciales falló.

Sin embargo, desde que comencé a trabajar con Linq en SQL, mis paradigmas han cambiado. Ya no hay necesidad de esto, ya que el modelo de Linq puede ser todo: objetos comerciales, objetos de transferencia y conjuntos de datos genéricos. Aún no he explorado qué tan bien funciona esto en aplicaciones realmente grandes, y si debería haber una necesidad de aislar el código front-end del modelo Linq. He tenido discusiones al respecto con mis colegas, sin realmente encontrar una respuesta de ninguna manera.

Answer 2

Me gusta la opción C pero también me da pausa por dos razones:

1. Tengo que difundir el conocimiento de lo que son los derechos en demasiados lugares.
2. Los DTO tienen que ser serializables, lo cual no es terrible, pero aún así es una consideración.

Answer 3

Si está utilizando un enfoque estratificado , lo que significa que todas las capas se ejecutan (esencialmente) en el mismo espacio de proceso y, por lo tanto, no hay marshalling / serialización, iré con el enfoque B. Cree un módulo separado para sus entidades sobre el cual todos los aspectos de su programa dependen, y par de eso.

Sin embargo, si usa un enfoque escalonado como lo sugiere su título, lo que significa que hay límites de proceso y / o de red que se cruzan, le sugiero que vaya con el enfoque C. En realidad, no está pasando ejemplos, usted re pasando copias, por lo que todos los beneficios que obtenga de acoplamiento al mismo objeto, como las opciones observables para, por ejemplo, un enfoque MVC, se pierden de todos modos. Es mejor definir API de datos en cada nivel de nivel que tratar de usar la misma clase por todas partes.

Answer 4

Supongo que las 3 capas existen dentro de la misma aplicación. En java al menos, he usado Hibernate para acceso a datos y he usado esos beans de datos en todas las capas. (opción B) Tiene sentido poder reutilizar tus entidades en tus capas.