Qual è l'approccio migliore quando si creano oggetti di accesso ai dati?

Question

Ho un metodo in MyWebpage.aspx.cs Lik così:

public partial class MyWebpage : PageBase 
{ 
    private readonly DataAccessLayer dataAccessLayer; 

    protected string GetMyTitle(string myVar, string myId) 
    { 
     if (string.IsNullOrEmpty(myVar)) 
     { 
      return string.Empty; 
     } 

     return dataAccessLayer.GetMyTitle(Convert.ToInt32(myId), myVar); 
    } 
} 

Nella classe DataAccessLayer, ho un methoud che parla al DB e fa la roba DAL e restituisce il titolo.

Qual è la procedura migliore per accedere al DAL dalla classe MyWebPage.aspx.cs (come in ho bisogno di creare ogni volta un nuovo oggetto DataAccessLayer()? Dove dovrei crearlo nella mia classe PageBase o ogni volta che lo chiamo in un codice dietro?

Answer 1

La prima cosa è accedere al DAL dal codice dietro o livello di presentazione in genere non è una buona pratica. Perché in questo caso è necessario inserire il codice di logica aziendale nel codice (Presentation Layer) che causa conflitti di preoccupazioni, elevato accoppiamento, duplicazione e molti altri problemi. Quindi, se siete cercare le migliori pratiche, suggerisco di dare un'occhiata ai seguenti link:

• Data Layer Guidelines
• Layered Application Guidelines
• Object-Relational Metadata Mapping Patterns (especially Repository Pattern) and Domain Logic Patterns

E questi sono veramente buoni libri :

• Patterns of enterprise application architecture (By Martin Fowler)
• Microsoft® .NET: Architecting Applications for the Enterprise

Avere anche una funzione statica per chiamare il DAL. Come sapete, le funzioni statiche sono vulnerabili al multi-threading, quindi se si utilizza qualcosa di condiviso nelle funzioni DAL (che talvolta è il caso, come la connessione condivisa, il comando, ecc.) Si romperà il codice, quindi penso sia meglio evitare le funzioni statiche in questo livello.

Answer 2

io sono un fan del repository pattern. Ognuno ha il proprio prendere su di esso, ma mi piace l'idea di una tabella SQL => un repository e condividere il nome, proprio come strumenti ORM.

Entity Framework potrebbe rendere rapido il lavoro del DAL ed è ancora possibile implementare un modello DAL come repository

Ecco un code generator che accetta una stringa di connessione SQL e fornisce un'implementazione abbastanza standard del blocco di applicazioni di accesso ai dati aziendali. Non è molto robusto in quanto è stato progettato contro uno schema blando sql. Se si utilizza il database di esempio, questo vi fornirà esempi di codice che è possibile utilizzare per progettare un livello di accesso ai dati a proprio piacimento.