Repositorio vs Acceso a datos

Question

En el contexto de la aplicación n-tier, ¿hay alguna diferencia entre lo que usted consideraría que son sus clases de acceso a datos y sus repositorios?

Tiendo a pensar que sí pero solo quería ver qué otro pensamiento. Mi opinión es que el trabajo del repositorio es solo contener y ejecutar la consulta en bruto, donde la clase de acceso a datos crearía el contexto, ejecutaría el repositorio (pasando en el contexto), manejaría el mapeo del modelo de datos al modelo de dominio y devolver el resultado nuevamente ...

¿Qué piensan? ¿Ves también algo de esto cambiando en un escenario de Linq a XML (suponiendo que cambias el contexto para el XDocument relevante)?

Saludos Anthony

ACTUALIZACIÓN:

Ésta es la manera que yo hubiera típicamente implementado con anterioridad cosas:

public class TermBl : ITermBl 
{ 
    public IEnumerable<ITerm> GetAll(IListParameter criteria) 
    { 
     //Any pre business logic 

     var dataLayer = this.CreateDataLayer(); 
     var result = dataLayer.GetAll(criteria); 

     //Any post business logic 

     return result; 
    } 

    ... Other methods 
} 

public class TermDa : ITermDa 
{ 
    public IEnumerable<ITerm> GetAll(IListParameter criteria) 
    { 
     //Linq query 
     var dataResult = ....ToList() 

     var mappedResult = this.FromDataToDomain(dataResult); 
     //Note the mapping isn't done in this object, the actual 
     // mapping is handled by a separate component 

     return mappedResult; 
    } 

    ... Other methods 
} 

, ¿existen otras problemas inherentes aquí con el patrón en general ..

En cuanto al repositorio en el que he estado pensando utilizarlo, en lugar de tener la consulta directamente en GetAll de TermDa método que cambiaría que se vea algo más parecido a esto:

public class TermDa : ITermDa 
{ 
    public IEnumerable<ITerm> GetAll(IListParameter criteria) 
    { 
     var repository = this.CreateRepository(); 
     var dataResult = repository.GetAll(..., criteria).ToList(); 

     var mappedResult = this.FromDataToDomain(dataResult); 

     return mappedResult; 
    } 

    ... Other methods 
} 

public class TermRepository : ITermRepository 
{ 
    public IQueryable<ITerm> GetAll(IMyContext context, IListParameter criteria) 
    { 
     //Linq query 
     return ...; 
    } 

    ... Other queries 
} 

¿Es así como ustedes lo ven trabajando o no realmente ... Con o sin el repositorio veo cualquiera de los anteriores totalmente la protección de la capa de negocio de saber algo sobre los métodos de acceso a los datos/tecnología utilizada ...

Answer 1

Sí, hay una gran diferencia.

• Un DAL (como una puerta de enlace de datos de la tabla) es un conceptobase de datos. Es responsable de emitir consultas a la base de datos y devolver conjuntos de registros.

• Un repositorio es un conceptodominio. Es responsable de aceptar solicitudes estructuradas y devolver objetos fuertemente tipados.

Muy diferente en la práctica.

---

Actualización:

La pregunta parece reflejar una cantidad significativa de confusión, así que vamos a tratar de aclarar con un ejemplo de código. Aquí hay un diseño que podría usar si no estuviera usando ningún ORM y estuviera haciendo su propia asignación en su lugar.Nada de esto es el código de calidad de producción, es sólo con fines educativos:

de acceso a datos:

public interface IOrderData 
{ 
    IDataReader GetOrder(int orderID); 
} 

public interface IOrderDetailData 
{ 
    IDataReader GetOrderDetails(int orderID); 
} 

public interface IProductData 
{ 
    IDataReader GetProduct(int productID); 
} 

Dominio:

public class Order 
{ 
    public int ID { get; set; } 
    public DateTime Date { get; set; } 
    public OrderStatus Status { get; set; } 
    // etc. 
    public IList<OrderDetail> Details { get; set; } 
} 

public class OrderDetail 
{ 
    public int ID { get; set; } 
    public Product Product { get; set; } 
    public int Quantity { get; set; } 
} 

Mapping:

public interface IDataMapper 
{ 
    Order MapOrder(IDataRecord record); 
    OrderDetail MapOrderDetail(IDataRecord record); 
    Product MapProduct(IDataRecord record); 
} 

Repositorio:

public interface IOrderRepository 
{ 
    Order GetOrder(int orderID); 
} 

public class OrderRepository 
{ 
    // These get initialized in the constructor 
    private readonly IOrderData orderData; 
    private readonly IOrderDetailData orderDetailData; 
    private readonly IProductData productData; 
    private readonly IDataMapper mapper; 

    public Order GetOrder(int orderID) 
    { 
     Order order; 
     using (IDataReader orderReader = orderData.GetOrder(orderID)) 
     { 
      if (!orderReader.Read()) 
       return null; 
      order = mapper.MapOrder(orderReader); 
     } 
     using (IDataReader detailReader = 
      orderDetailData.GetOrderDetails(orderID)) 
     { 
      while (detailReader.Read()) 
      { 
       OrderDetail detail = mapper.MapOrderDetail(detailReader); 
       detail.Product = ...; // Omitted for brevity, more reading/mapping 
       order.Details.Add(detail); 
      } 
     } 
     return order; 
    } 
} 

¿Es esta haciendo más sentido ahora? El DAL está tratando con datos. El Repositorio concreto puede encapsular clases de acceso a datos pero el repositorio abstracto (su interfaz pública) solo trata con clases de dominio.

Una vez más recordaré a los lectores que esto ni siquiera está cerca del código de calidad de producción, y que la mayoría de las aplicaciones actuales usan un ORM o al menos alguna forma mejor de asignación automática. Esto es solo para fines ilustrativos.

Answer 2

Parece que tiene un buen control sobre él. Las "clases de acceso a datos" pueden tomar muchas formas diferentes. Es un tipo de clase que tiene algo que ver con el acceso a los datos. Su Repositorio es (A) un patrón para manejar su persistencia de datos, y (B) un lugar dentro de su esquema de acceso a datos (si está implementando un repositorio).

Un desafío en su estrategia de acceso a datos es proporcionar flexibilidad y capacidad reutilizable al mismo tiempo. Mientras que al mismo tiempo es eficiente. Mientras que al mismo tiempo trabaja con su lógica de negocio, estando desacoplado pero también siendo cohesivo. Difícil.

El repositorio es un patrón que pretende ayudar con todo este equilibrio. Su código para traducir el db (o lo que sea) a/de las clases de entidad reside en un lugar, para cada entidad. Sus "clases de acceso a datos" pueden consistir en sus clases de repositorio, así como en las clases que realmente manejan el trabajo SQL. Ciertamente no deberías estar haciendo todo el sql cruft dentro de cada una de tus clases de repositorio.

Ejemplo: puede comenzar utilizando la reflexión ineficiente pero fácil para completar los objetos de su entidad, haciendo casi ningún trabajo en sus clases de repositorio; más tarde puede hacerlo más eficiente para entidades de gran volumen, pero esto está completamente oculto de otras partes de su sistema. Y luego, mueve una configuración a XML, pero el resto de su sistema no tiene idea de este cambio.

LINQ-to-sql y Entity framework realmente aprovechan el patrón de repositorio, porque lo que devuelven las clases de repositorio es realmente un IQuerable de esa entidad. Las clases de negocios pueden aplicar criterios adicionales, y esos criterios en realidad llegan al sql, a la vez que proporcionan una encapsulación completa a partir de la persistencia de los datos. Es realmente genial.