arquitectura de n-capas - BLL, DAL y las interfaces. ¿Cuál es la mejor práctica?

Question

Tengo una pregunta con respecto a la arquitectura n-capa. Pensé mucho antes de hacer esta pregunta ya que hay un montón de preguntas similares aquí ya ... Sin embargo, después de, literalmente, un día y medio mirando y leyendo estas otras respuestas Todavía estoy seguro. La variedad de la terminología y los diferentes enfoques aparentemente similares me tiene confundido.

Si tuviera un BLL y una DAL en diferentes bibliotecas de clases, una forma de comunicación entre el BLL y DAL sería utilizar una interfaz, como una especie de DTO definida en otro archivo DLL independiente que se hace referencia por tanto BLL y DAL . Mis entidades del modelo de dominio en el BLL implementarían esta interfaz y por lo haría con cualquier ORM generada objetos en el DAL. Para guardar mis entidades empresariales que pude y luego pasarlas al DAL que aceptarlos bien porque implementan la interfaz compartida. También pude pasar objetos atrás a la BLL que implementan esta interfaz. Esto parece razonable ya que tanto BLL y DAL a continuación, sólo tiene que ser consciente de la interfaz básica, no cada uno de los demás aplicación concreta.

Mi pregunta es ¿qué es lo que es el mejor método para crear el objeto en el otro lado? Por ejemplo, si tuviera un objeto Person en el BLL que implementó IPerson, y una PersonDataObject o lo que sea en la DLL que también implementa IPerson, paso persona a un método en el DAL que toma un parámetro de IPerson, a continuación, en el DAL I' d tienen para reconstruir una PersonDataObject a persistir. ¿Es esto el mejor método?

Lo siento, probablemente no han explicado esto muy bien como estoy bastante confundido. Una buena práctica para los maniquíes respuesta sería muy apreciada.

Answer 1

En términos generales, los objetos en el BLL consumirá las interfaces - no ponerlas en práctica:

  

Por ejemplo, si yo tenía un objeto Person   BLL en el que implementó IPerson,   y una PersonDataObject o lo que sea en   la DLL que también implementa IPerson

Tomar una "persona" como un ejemplo: pensar en las diferentes operaciones de datos asociados con una persona (Obtener todos los datos para una sola persona, una colección de datos de poca profundidad para muchas personas, un mantenimiento, buscar, etc) - a continuación, interfaces de diseño a lo largo de agrupaciones lógicas (véase la Interface Segeragtion Principio ).

Las interfaces podría representar operaciones desde una perspectiva BL centrada -. O un "servicio" uno basado

De todos modos, para responder a su pregunta específica ...

Me definir mi equivalente de DTO en una asamblea común, y la interfaz de datos en un uno por separado, así - así que tengo 4 asambleas: BL, datos de definición de acceso Inteface, la implementación de la interfaz y comunes; todos los conjuntos de referencia el común.

Estoy trabajando en C # .Net, defino los dtos como estructuras (pero se puede usar clases); y todas las propiedades de estos son de sólo lectura - usted alimenta a los datos en ellos en el constructor -. De esta manera los de DTO son effectly sobres 'tontas' de información

Answer 2

Mientras que sigue la arquitectura de n niveles, es muy común para compartir los objetos de datos entre BL y DAL. A veces, el mismo objeto de datos puede ser utilizado en la capa de interfaz de usuario también.

Por lo general, tengo un modelo de datos (o los objetos de datos o modelo de dominio, lo que sea lo que sea) de montaje que las casas de todos los modelos de objetos como interfaces. Tomando su ejemplo la gente, voy a crear una interfaz iPeople en modelo de ensamblaje. DAL devolverá una instancia de iPeople a BL. BL consumirá este caso y, si es necesario pasar esto a la capa de interfaz de usuario después de la aplicación lógica de negocio.

Answer 3

Google para el diseño de dominio impulsada y el modelo de repositorio. Se soumnds como se dirige en esa dirección con su arquitectura y en función de que el escenario lo justifica me gustaría utilizar este enfoque en un código más complicado.