Qué objetos debe devolver desde la capa de acceso a datos a la capa empresarial un sistema n-tier

Question

Si tiene, por ejemplo, una tabla de base de datos llamada Persona (ID, Nombre, etc.) qué tipo de objeto debe devolver el nivel de acceso a datos para el nivel de negocios? estoy pensando algo como esto:

//data access tier 
public class DataAccess{ 

    public interface IPerson{ 
     int ID{ get; set; } 
     string Name{ get; set; } 
    } 

    internal class Person : IPerson{ 
     private int id; 
     private string name; 

     public int ID{ get{return id; } set{ id=value; } } 
     public int Name{ get{retutn name; } set{ name=value; } 
    } 

    public static IPerson GetPerson(int personId) 
    { 
     //get person record from db, populate Person object 
     return person; 
    } 
} 

//business tier 
public class Person : IPerson{ 
    private int id; 
    private string name; 

    public int ID{ get{return id;} set{id=value;} } 
    public string Name{ get{return name;} set{name=value;} } 

    public void Populate(int personId){ 
     IPerson temp = DataAccess.GetPerson(personId); 
     this.ID = temp.ID; 
     this.Name = temp.Name; 
    } 
} 

Pero todo esto parece un poco engorroso? ¿Hay una solución más elegante para este problema? ¿Debo devolver un DataRow de la capa de acceso a datos a la capa de negocios?

Answer 1

No necesita repetir la definición de clase en su capa de acceso a datos (DAL).

Puede crear sus entidades comerciales como contenedores 'tontos' en un ensamblaje por separado, p. su clase Persona puede ser: -

public class Person 
{ 
    int ID { get; set: } 
    string Name { get; set: } 
} 

Luego, puede darle a su DAL una referencia a la capa de entidades comerciales. Sus objetos de controlador, ya sea que se encuentren en una capa de lógica de negocios separada o dentro de su capa de interfaz de usuario, pueden simplemente llamar al DAL, que puede crear una entidad comercial, llenarla de la base de datos y devolverla a su controlador.

This article de Imar Spaanjaars tiene una buena explicación de este patrón.

Answer 2

La capa empresarial definitivamente no quiere saber acerca de las filas de datos: intente dejar clases específicas de datos en la capa de datos. Esto reduce el acoplamiento y lo libera para cambiar su capa de persistencia en una fecha posterior sin una nueva arquitectura mayorista.

Para resolver su problema específico, puede:

• Crear objetos de datos/entidades básicas en su capa de datos y la mano fuera de su capa de negocio para el consumo.
• O, como parece que está haciendo, cree DTO (Objetos de transferencia de datos) que existen puramente como un medio de transferir datos de la capa de datos a una implementación más rica de su objeto comercial en una capa superior. Puede hacer esto como parte de un patrón de repositorio en un modelo de dominio enriquecido.

La otra cosa en la que quizás quieras pensar es en las capas v las capas: hace una diferencia cómo piensas sobre estas cosas. Los niveles son generalmente físicos, en otras palabras, definen los límites entre los procesos. Las capas son generalmente lógicas, separan la funcionalidad de un programa en unidades débilmente acopladas. Estás apuntando a capas en este caso.

Answer 3

Si crea interfaces para sus clases DAO y las coloca dentro de su nivel empresarial, puede hacer referencia a su nivel empresarial desde el nivel de acceso a datos. Las clases DAO en el nivel de datos devuelven objetos del nivel empresarial.

Su nivel de negocio hace referencia a las interfaces en lugar de hacer referencia directa a los objetos de acceso a datos. La inyección de dependencia a través de un contenedor IoC (como Castle Windsor, por ejemplo) le permitirá lograr esto.

Esta técnica se denomina interfaz separado y se describe aquí:

http://www.martinfowler.com/eaaCatalog/separatedInterface.html

La mejor explicación de esta técnica que he visto se puede encontrar en este artículo sobre las mejores prácticas NHibernate, escrito por Billy McCafferty.

http://www.codeproject.com/KB/architecture/NHibernateBestPractices.aspx

El artículo tiene una gran cantidad de información que es específica para NHiberbate, pero una buena mitad de ella es sólo información sólida sobre el diseño de aplicaciones que se acopla libremente y fácilmente unidad probada.

Answer 4

Como esta regla dice que cada capa tiene que acoplarse libremente a la capa superior, agregar una referencia BL a DAL no es una buena idea. Es mejor definir el modelo de datos en DAL con una interfaz y hacer que las entidades comerciales se formen en BL. según mis experiencias, es mejor utilizar el Repositorio en DAL y acceder en su Entidad comercial o Proceso comercial.