La comunicación entre BLL y DAL

StackOverflow https://stackoverflow.com/questions/3952534

Pregunta

configuración Solución:

  • DAL (biblioteca de clases)
  • BLL (biblioteca de clases)
  • Común (biblioteca de clases (algunas funciones comunes - enumeraciones, la explotación forestal, excepciones, ...))
  • Application1 (Solicitud de Windows)
  • Application2 (Solicitud de Windows)
  • aplicación web (aplicación web)
  • ...

Vamos a decir que tengo un cliente entidad, que es:

  • una tabla en SQL Server
  • a CustomerDataTable en DAL
  • una clase de atención al cliente en BLL
  • una clase BLL.Customer en todas las aplicaciones

¿Qué tipo de objetos deben BLL y DAL uso para la comunicación - DataTable o List<Customer> (por ejemplo)? En primer caso, la lógica debe BLL objeto de transformación de cliente a DataTable y enviarlo a DAL. En caso secod, capa DAL debe ser consciente de la clase de atención al cliente, que está en la capa BLL. Pero las referencias DLL originalmente DAL y no opuesta ...

¿Debo poner todas las clases en el conjunto independiente, que está referenciado por todos los demás (comunes, BusinessObjects, ...)? En este caso yo podría utilizar la clase de atención al cliente en todos mis proyectos.

¿Debo siquiera se molestó en DAL separado y BLL cuando sé, que sólo un BLL utilizará mi DAL. En este caso pude unirlos en un solo proyecto.

PS - Estoy leyendo sobre tablas de datos y mucha gente dice que no hay que usarlos en absoluto. ¿Cuáles son las mejores opciones? Tal vez ha llegado el momento para mí de aprender algunas herramientas de mapeo ORM:)

¿Fue útil?

Solución

En mi opinión usted debe tener otra capa (DLL separado). Al igual que "dominio", ¿dónde guardar todas las entidades como de los clientes. Después, simplemente incluir en todos los niveles superiores (DAL, BLL, interfaz de usuario y otros) en la jerarquía de este conjunto.

Arquitectura de ejemplo puede tener este aspecto:

(base de datos) <-> DAL <-> BL <-> UI

y en todos los niveles tendrá acceso a la capa de "dominio". Lista DAL no un DataTable debe devolver. En alguna etapa de su proceso de desarrollo es posible que desee utilizar en algunos DAL OMR como NHibernate con que también devolver una lista, probablemente.

Otros consejos

es difícil responder a esta pregunta general sin conocer el dominio de aplicación lo suficientemente bien. Me gustaría empezar con el pensamiento acerca de dónde son más propensos cambios en el futuro y tratar de averiguar de que cuando se requiere flexibilidad.

mi siguiente pensamiento son sólo una sugerencia. no dude en considerarlos y / cambio de ignorar lo que sientes es irrelevante.

separar el DAL de la BLL es casi siempre una buena idea. el esquema de datos es una cosa que debe ser encapsulado y oculta para el resto de la aplicación, por lo que dejar sus DataTables, conjuntos de datos ORM o cualquier otra solución escondido en el DAL. la BLL (y las capas por encima de ella) deben usar tipos de datos simples (es decir, las clases simples). Creo que sería una buena idea poner esas clases en una biblioteca de clases de modelo que no tiene referencias y se puede utilizar en todas partes.

se siente como que tiene un poco demasiado estratificación ... lo que realmente necesita una clase de atención al cliente en el BLL y otra en la capa de aplicación? podría ser, pero me aseguraría y pensar dos veces más.

de mi experiencia en uno de mi reciente proyecto (un sitio web con el tiempo 200K visitantes únicos al día), que utiliza link2sql para acceso a datos (en su mayoría sólo lectura de datos), y las clases de datos simples en toda nuestra aplicación ASP.Net MVC ( por supuesto, como parte de modelos / ver modelos). funcionó bastante bien, y que fácilmente podría cambiar el esquema de datos sin romper otras capas.

En cuanto a su última pregunta sobre tablas de datos, estos objetos, si decide usarlos (Votaría en contra), pertenecen exclusivamente en su DAL. que no deben ser expuestos a otras capas como que crearía acoplamiento a esa clase específica. ¿y si mañana MS inventa una mejor clase? le conmutar ahora que tiene un tropecientos referencias por todas partes sus proyectos a la tablas de datos, su método y propiedades? sería mejor que acaba de cambiar su DAL a trabajar con la clase NewAwsomeDataTable y el resto de su aplicación es felizmente ignorante.

esperanza de que ayudó:)

Yo usaría el siguiente patrón, ya que le permite actualizar a una estrategia de persistencia diferente en el futuro. 

UI/Consumer  <--- (view models) --> BLL <--- Models ----> DAL/Persistence

A continuación, los modelos de vista se consumen fuera de la BLL y modelos se comunican a través de las capas BLL / DAL.

En su caso, el modelo puede ser cualquier cosa los usos DAL - Tablas de datos, por ejemplo, o entidades más adelante quizá ORM. El BLL es responsable de mapeo entre el modelo y la vista del modelo.

En cuanto al mantenimiento de tipos en sus propias asambleas - sí a favor de modelos de vista y con el fin de mantener una consistencia, sí para los modelos también.

Mantener los modelos y los modelos de visualización distintos paradas de fuga de las estrategias de persistencia fuera de la BLL y por lo tanto permite que los futuros cambios de diseño en la persistencia.

Una ventaja de esta separación es que que los diferentes consumidores vista de modelo pueden tener diferentes modelos de vista para el mismo modelo de persistencia / entidad. Algunos de ellos podrían ser pequeñas y tienen pocos atributos y otras grandes y ricos en funcionalidad. También permite que usted pueda introducir sin conexión / desconexión capacidad como los modelos de vista podrían ser devueltos en momentos diferentes lo que le permite decidir la fusión de datos de estrategias. Esto también le permite estés entidades de persistencia (por ejemplo, tablas de crecer y cambiar de forma). Dado que esto parece una implementación de .NET cosas como AutoMapper proporcionará una gran cantidad de funcionalidad de la caja

Por supuesto, esto puede ser una forma excesiva para su aplicación - sin embargo yo sigo manteniendo una correspondencia BLL que sólo habla ver modelos para todos los consumidores BLL. Esto debe darle suficiente desacoplamiento.

Empujar las entidades del dominio en el dal es una opción que eliminaría la dependencia crcular, pero puede que no coincida con su intención. Esto no es desconocida, sin embargo; por ejemplo LINQ a SQL gnerated entidades vivirían en el DAL.

Otras opciones:

  • los puso en un común Baja Montaje (pero que puede dejar su BL bastante vacío)
  • utilizar COI para eliminar / invertir la referencia entre BL / DAL

No existen respuestas individuales a la derecha aquí.

Re DataTable; personalmente estoy de acuerdo - No soy un ventilador;) Sin embargo, pueden ser utilizados con éxito y razonablemente. Pero si Had para usarlos, estaría mantenerlos en el DAL como un detalle de implementación -. Y no exponerlos por encima de ese

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top