¿Qué objetos en caso de que regrese de la capa de acceso de datos a la capa de negocio un sistema de n niveles

Question

Si usted tiene, por ejemplo, una tabla de base de datos llamada Persona (identificación, nombre, etc.) qué tipo de objeto si el acceso a los datos de nivel de retorno a la capa de negocio? Estoy pensando en 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 a este problema? Debería devolver un DataRow de la capa de acceso de datos a la capa de negocio en su lugar?

Answer 1

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

Usted puede crear sus entidades empresariales como recipientes 'muda' en un montaje por separado, por ejemplo la clase de persona solo puede ser: -

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

A continuación, se puede dar a su DAL una referencia a la capa de entidades de negocios. Sus objetos del controlador, tanto si están en una capa de lógica de negocio separada, o dentro de la capa de interfaz de usuario, pueden entonces simplemente llamar a la DAL, que puede crear una entidad comercial, poblarlo de la base de datos y devolverlo a su controlador.

Este artículo por Imar Spaanjaars tiene una buena explicación de este patrón.

Answer 2

Su capa de negocio definitivamente no quiere saber acerca de las filas de datos - tratar de salir de datos de clases específicas en la capa de datos. Esto reduce el acoplamiento y le libera para cambiar la capa de persistencia en una fecha posterior sin por mayor re-architecting.

Para resolver su problema específico, puede:

• Crear datos de objetos / 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, crear DTO (objetos de transferencia de datos) que existen meramente como un medio de transferencia de datos de la capa de datos a una aplicación más rico de su objeto de negocio en una capa superior. Es posible hacer esto como parte de un patrón de repositorio en un modelo de dominio rico.

La otra cosa que puede que desee pensar en gradas es v capas - se hace una diferencia de cómo se piensa en estas cosas. Los niveles son generalmente física, en otras palabras que definen los límites entre los procesos. Las capas son generalmente lógico, se separan la funcionalidad de un programa en unidades de forma flexible. Usted está apuntando para capas en este caso.

Answer 3

Si crea interfaces para sus clases DAO y colocarlos dentro de su capa de negocio, puede hacer referencia a su nivel de negocio desde el nivel de acceso a datos. Las clases DAO en el regreso nivel de datos objetos de la capa de negocio.

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

Esta técnica se llama separado interconectado 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 de 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 de que cada capa tiene por qué-débilmente acoplados a la capa superior, se agregue una referencia a BL DAL no es buena idea. Su definir mejor modelo de datos en DAL con una interfaz y crea la forma de entidad de negocios en BL. como mi experiencia, es mejor usar Repositorio de DAL y el acceso en en su entidad de negocio o de procesos de negocio.