Repository vs Data Access

Question

Nel contesto dell'applicazione n-tier, c'è una differenza tra ciò che considerereste le vostre classi di accesso ai dati e i vostri repository?

Tendo a pensare sì ma volevo solo vedere quale altro pensiero. Il mio pensiero è che il lavoro del repository è solo per contenere ed eseguire la query raw stessa, dove come la classe di accesso ai dati creerebbe il contesto, eseguire il repository (passando nel contesto), gestire il mapping del modello di dati al modello di dominio e restituisci il risultato ...

Cosa ne pensate? Vedete anche questo cambiamento in uno scenario da Linq a XML (assumendo che si cambi il contesto per il relativo XDocument)?

Saluti Anthony

UPDATE:

Questo è il modo in cui avrei tipicamente implementato cose in precedenza:

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 
} 

Vede qualche problemi inerenti qui con il modello in generale ..

Per quanto riguarda il repository in cui ho pensato di utilizzarlo è invece di avere la query direttamente nel GetAll di TermDa Metodo vorrei cambiare farlo sembrare qualcosa di più simile a questo:

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 
} 

È così che ragazzi vederlo lavorare o no davvero ... Con o senza il repository che vedo uno di quanto sopra totalmente protezione dello strato di business da sapere tutto sui metodi di accesso ai dati/tecnologia utilizzata ...

Answer 1

Sì, c'è una grande differenza.

• Un DAL (come ad esempio un gateway dati Tabella) è un concettodatabase. È responsabile per l'emissione di query nel database e la restituzione dei set di record.

• Un repository è un concettodominio. È responsabile dell'accettazione delle richieste strutturate e della restituzione degli oggetti con caratteri corretti.

Molto diverso nella pratica.

---

Aggiornamento:

La domanda sembra riflettere una notevole quantità di confusione, in modo da farmi provare a chiarire con un esempio di codice. Ecco un disegno che potresti usare se non stavi usando un ORM e invece stavi facendo tutto il tuo mapping.Niente di tutto questo è il codice di produzione di qualità, è solo per scopi didattici:

accesso ai dati:

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

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

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

Domain:

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); 
} 

Repository:

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; 
    } 
} 

È questo rendendo più senso ora? Il DAL si occupa di dati. Il repository concreto può incapsulare classi di accesso ai dati, ma il repository astratto (la sua interfaccia pubblica) tratta solo le classi di dominio.

Ancora una volta mi limiterò a ricordare ai lettori che questo non è nemmeno vicino al codice di qualità di produzione e che oggi la maggior parte delle app utilizza un ORM o almeno una forma migliore di mappatura automatica. Questo è solo a scopo illustrativo.

Answer 2

Sembra che tu abbia una buona idea. "Le classi di accesso ai dati" possono assumere molte forme diverse. È una sorta di classe che ha qualcosa a che fare con l'accesso ai dati. Il tuo Repository è (A) un modello per la gestione della persistenza dei dati e (B) un posto all'interno del tuo schema di accesso ai dati (se stai implementando il repository).

Una sfida nella strategia di accesso ai dati offre allo stesso tempo flessibilità e capacità riutilizzabili. Mentre allo stesso tempo è efficiente. Mentre allo stesso tempo lavorate con la vostra logica aziendale, essendo disaccoppiati ma anche essendo coesivo. Difficile.

Il deposito è uno schema che si propone di aiutare con tutto questo equilibrio. Il codice per la traduzione del db (o di qualsiasi altra cosa) da/verso le classi di entità risiede in un posto, per ciascuna entità. Le tue "Classi di accesso ai dati" potrebbero consistere nelle tue classi di repository e in quelle che effettivamente gestiscono il lavoro di sql. Certamente non dovresti fare tutto il sql cruft all'interno di ciascuna delle tue classi di repository.

Esempio: è possibile iniziare a utilizzare una riflessione inefficiente ma facile per riempire gli oggetti di entità, facendo quasi nessun lavoro nelle classi del repository; in seguito è possibile renderlo più efficiente per le entità ad alto volume, ma questo è completamente nascosto da altre parti del sistema. E in seguito si sposta qualche configurazione in XML, ma il resto del sistema non ha idea di questo cambiamento.

LINQ-to-sql e Entity framework sfruttano realmente il pattern di repository, perché ciò che restituiscono le classi di repository è in realtà un IQuerable di quell'entità. Le classi di business possono applicare criteri aggiuntivi e tali criteri lo rendono effettivamente al sql, pur continuando a fornire un incapsulamento completo dalla persistenza dei dati. È davvero fantastico.