pasando los datos en una aplicación ntier

Question

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

A) .net genérica objetos genéricos tablas de datos, tablas hash, conjuntos de datos genéricos, cuerdas, etc ... Ints a continuación, utilizando los conjuntos de datos para llenar sus objetos de negocio, que son enviadas a la capa de interfaz de usuario.

alt text http://img11.imageshack.us/img11/460/generic.png

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

Pro- No hay capas adicionales necesarios Con- tiene que trabajar con conjuntos de datos genéricos y mesas en la capa de negocio

B) usando una capa de entidades que las otras capas w ould 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.

alt text http://img8.imageshack.us/img8/6454/entities.png

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

Pro- trabajar con las mismas clases en todas las capas Con- añadir una referencia a entities.dll a todas las capas

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

alt text http://img43.imageshack.us/img43/1236/transferp.png

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

Pro- la capa de negocio no tendría que trabajar con clases genéricas Con- trabajar con dos tipos de objetos y que tendría para 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

Si está utilizando un enfoque capas, es decir, todas las capas se (esencialmente) que se ejecutan en el mismo espacio de proceso y por lo tanto no hay ningún cálculo de referencias/serialización, me gustaría ir con enfoque B. Crear un módulo separado para sus entidades de las que dependen todos los aspectos de su programa, y ​​unidas a eso.

Sin embargo, si usted está usando un enfoque secuencialcomo su título indica, significa que hay límites de proceso y/o de red que se cruzan, sugeriría que vaya con enfoque C. Usted no está realmente pasando instancias, está pasando copias, por lo que todos los beneficios que obtenga al vincularse 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 2

me gusta la opción C, pero también me da que pensar, por dos razones:

1. que tienen que difundir la knwowledge de lo que los properites están en demasiados lugares.
2. DTO tienen que ser serializables, lo cual no es terrible, pero aún así es una consideración.

Answer 3

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

Answer 4

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

Sobre el tipo de aplicación, y si realmente es necesario tener objetos comerciales (Entidades), en lugar de transferir objetos (es decir, objetos comerciales simplificados que corresponden más a entidades de base de datos).

Tradicionalmente, habría argumentado que siempre necesita conjuntos de datos genéricos (o tablas de datos), solo 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.