.net - programacion - ¿Qué objetos debería devolver desde la capa de acceso a datos a la capa empresarial un sistema de n niveles?

manual de programacion android pdf

Question

Si tiene, por ejemplo, una tabla de base de datos llamada Persona (ID, Nombre, etc.), ¿qué tipo de objeto debería devolver el nivel de acceso a datos al nivel empresarial? 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

Su capa de negocios definitivamente no quiere saber acerca de las filas de datos: trate de 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:

• Cree objetos / entidades de datos básicos en su capa de datos y transfiéralos a su capa empresarial para su consumo.
• O, como parece que está haciendo, cree DTO (Objetos de transferencia de datos) que existen puramente como un medio para transferir datos de la capa de datos a una implementación más completa 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 los niveles 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 2

Si crea interfaces para sus clases DAO y las coloca dentro de su nivel comercial, 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 llama interfaz separada 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 mucha información que es específica de NHiberbate, pero una buena parte es solo información sólida sobre el diseño de aplicaciones que se acoplan libremente y se prueban fácilmente en unidades.

Answer 3

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 separado, por ejemplo, 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.

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

Answer 4

Como esta regla establece que cada capa tiene que estar flojamente acoplada 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 la entidad empresarial se forme en BL. según mis experiencias, es mejor utilizar el Repositorio en DAL y acceder en su Entidad comercial o Proceso comercial.