Quali oggetti si devono restituire dal livello di accesso ai dati al livello aziendale un sistema a più livelli

Question

Se si dispone, ad esempio, di una tabella di database denominata Persona (ID, Nome, ecc.) Quale tipo di oggetto deve restituire il livello di accesso ai dati al livello aziendale? sto pensando qualcosa di simile:

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

Ma tutto questo sembra un po 'ingombrante? C'è una soluzione più elegante a questo problema? Devo restituire un DataRow dal livello di accesso ai dati al livello aziendale?

Answer 1

Non è necessario ripetere la definizione della classe nel livello di accesso ai dati (DAL).

È possibile creare le entità aziendali come contenitori "stupidi" in un assieme separato, ad es. la classe Persona può essere solo: -

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

Quindi, è possibile assegnare al DAL un riferimento al livello delle entità aziendali. Gli oggetti del controller, indipendentemente dal fatto che si trovino in un livello di business logic separato o all'interno del livello dell'interfaccia utente, possono quindi semplicemente chiamare il DAL, che può creare un'entità aziendale, popolarlo dal database e restituirlo al controller.

This article di Imar Spaanjaars ha una bella spiegazione di questo modello.

Answer 2

Il tuo livello aziendale non vuole assolutamente conoscere le righe di dati: prova a lasciare classi specifiche di dati nel livello dati. Questo riduce l'accoppiamento e ti libera di cambiare il tuo livello di persistenza in un secondo momento senza una nuova progettazione.

Per risolvere il problema specifico, è possibile:

• Creazione di oggetti di dati di base/entità nel vostro livello di dati e li mano fuori al vostro livello di business per il consumo.
• Oppure, come sembra, creare DTO (oggetti di trasferimento dati) che esistono puramente come mezzo per trasferire i dati dal livello dati a un'implementazione più ricca dell'oggetto business in un livello superiore. È possibile farlo come parte di un modello di repository in un modello di dominio ricco.

L'altra cosa a cui si potrebbe pensare è livelli in livelli: fa la differenza come si pensa a queste cose. I livelli sono generalmente fisici, in altre parole definiscono i confini tra i processi. I livelli sono generalmente logici, separano le funzionalità di un programma in unità liberamente accoppiate. In questo caso stai mirando agli strati.

Answer 3

Se si creano interfacce per le classi DAO e le si posizionano all'interno del livello aziendale, è possibile fare riferimento al livello aziendale dal livello di accesso ai dati. Le classi DAO nel livello dati restituiscono oggetti dal livello aziendale.

Il livello aziendale fa riferimento alle interfacce anziché fare riferimento direttamente agli oggetti di accesso ai dati. L'iniezione delle dipendenze tramite un contenitore IoC (come ad esempio Castle Windsor) ti consentirà di farlo.

Questa tecnica è chiamata separato interfacciata ed è descritta qui:

http://www.martinfowler.com/eaaCatalog/separatedInterface.html

La migliore spiegazione di questa tecnica che ho visto si possono trovare in questo articolo su NHibernate migliori pratiche, scritto da Billy McCafferty.

http://www.codeproject.com/KB/architecture/NHibernateBestPractices.aspx

L'articolo ha un sacco di informazioni che è specifico per NHiberbate, ma una buona metà di esso è solo informazioni solido sulla progettazione di applicazioni di essere debolmente accoppiati e facilmente unità testata.

Answer 4

Come regola per cui ogni livello deve essere collegato in modo lasco al livello superiore, l'aggiunta del riferimento BL a DAL non è una buona idea. Definisce meglio il modello di dati in DAL con un'interfaccia e crea il modulo Entità aziendale in BL. come mie esperienze, è meglio usare il repository in DAL e accedere al tuo business Entity o Business Process.