arquitectura de 3 capas: paso de datos entre capas

Question

tratando de implementar 3 capas (no: nivel, solo quiero separar mi proyecto lógicamente, en una máquina) arquitectura He encontrado tantos enfoques diferentes que estoy confundido , ¿cuál es la mejor manera (si hay alguna) para hacer eso en la aplicación WinForms.

ahora no tengo dudas sólo alrededor de 3 capas que deben estar presentes en el proyecto:

• interfaz de usuario (capa de presentación)
• BLL (lógica de negocios Layer)
• DAL (datos de acceso Layer)

En UI Puse todos los WinForms. También debe haber alguna lógica para llenar el objeto con datos de controles y pasarlo a la capa BLL.

En DAL quiero poner las clases y los métodos para la manipulación de los datos con ADO.NET, como:

public class OrderDAL 
{ 
    public OrderDAL() 
    { 
    } 

    public int Add(Order order) 
    { 
     //...add order to database 
    } 

    public int Update(Order order) 
    { 
     //...update order in database 
    } 

    //...etc. 
} 

el problema es con BLL y la pregunta - debo usar Transferencia de objetos de datos a pasar datos entre capas, o debería pasar toda la clase?

Si decido utilizar DTO, entonces tengo que crear la clase ordinaria adicional, Order, que la referencia a la interfaz de usuario, y BLL DAL:

public class Order 
{ 
    public int Id { get; set; } 
    public DateTime Date { get; set; } 
    public string Number { get; set; } 
    public string CustomerName { get; set; } 

    public Order() 
    { 
    } 
} 

y poner la lógica separados en BLL :

public class OrderBLL 
{ 
    public OrderBLL() 
    { 
    } 

    public int Add(Order order) 
    { 
     OrderDAL orderDAL = new OrderDAL(); 
     return orderDAL.Add(order); 
    } 

    public int Update(Order order) 
    { 
     OrderDAL orderDAL = new OrderDAL(); 
     return orderDAL.Update(order); 
    } 

    //...etc. 
} 

Este enfoque, bajo diferentes nombres, se utiliza entre otros: here o here.
Por otro lado, algunos "tipos sabios" y sus seguidores (como here) lo llaman Anemic Domain Model y se quejan de que es un mal diseño y antipatrón que no debe utilizarse.

Los pros:

• DTO puede fácilmente por diseño para representar la tabla de base de datos,
• es ligero y claro, contiene sólo los campos necesarios para la base de datos,
• DAL no tiene que hacer referencia a BLL,

Los contras:

• anti-patrón (sonidos de miedo; P),
• violación de OOP (propiedades separadas de métodos),
• porque la lógica está en diferente clase, puede ser más difícil de mantener cuando algo cambia.

Por lo tanto, el enfoque contrario es pasar todo el objeto entre las capas, como here: no DTO, simplemente BLL con ese aspecto:

public class Order 
{ 
    public int Id { get; set; } 
    public DateTime Date { get; set; } 
    public string Number { get; set; } 
    public string CustomerName { get; set; } 

    public Order() 
    { 
    } 

    public int Add() 
    { 
     OrderDAL orderDAL = new OrderDAL(); 
     return orderDAL.Add(this); 
    } 

    public int Update(Order order) 
    { 
     OrderDAL orderDAL = new OrderDAL(); 
     return orderDAL.Update(order); 
    } 
} 

Los pros:

• es un objeto muy bien encapsulado, siguiendo las reglas de OOP (supongo;)).
• Tanto la lógica como las propiedades están en un solo lugar, son más fáciles de mantener y depurar.

Los contras:

• utilizar el objeto, DAL tiene que hacer referencia a BLL (que no es la forma en la capa de 3 niveles deben hacer, no?).
• La clase puede contener algunos campos que no se usan en la Base de datos, y algunos campos de la Base de datos (como Id) no representan el objeto "de la vida real".

Por lo tanto, parece lo que elija, voy a violar algunas reglas. ¿Cuál es la mejor manera entonces, cuál debería elegir? Tal vez hay otro enfoque que no he encontrado?

Answer 1

No me gustan los DTO, porque significan crear una jerarquía dual con poco o ningún valor.

Tampoco me gusta la idea de hacer que los objetos modelo sean responsables de su propia persistencia. Prefiero una capa de persistencia separada. ¿Por qué? Los objetos modelo no siempre necesitan persistir para ser útiles. La lógica y la funcionalidad empresarial son ortogonales a la persistencia.

Si tiene dos capas, es posible mantener un gráfico de dependencia de una vía: la persistencia conoce el modelo, pero el modelo no sabe acerca de la persistencia. Usted termina con una dependencia cíclica si los objetos modelo son responsables de la persistencia. Nunca puede probar o usar objetos modelo sin persistencia de.

Mi consejo? No hagas DTOs. Divide una capa de persistencia separada.