Quali oggetti si dovrebbe tornare dal livello di accesso ai dati al livello di business un sistema a più livelli

Question

Se si dispone, ad esempio, una tabella di database denominata persona (ID, nome, ecc) che tipo di oggetto qualora l'accesso ai dati di livello ritorno 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? Esiste una soluzione più elegante a questo problema? Devo restituire un DataRow dallo strato di accesso ai dati al livello di business, invece?

Answer 1

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

È possibile creare le entità di business come contenitori 'stupidi' in un assembly separato, per esempio la classe Persona può essere solo: -

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

Quindi, potete dare il vostro DAL un riferimento al livello di entità di business. I suoi oggetti controller, siano essi in uno strato logica di business separata, o all'interno del vostro livello di interfaccia utente, possono quindi basta chiamare il DAL, che può creare un ente commerciale, popolarlo dal database e restituirlo al controller.

questo articolo di Imar Spaanjaars ha una bella spiegazione di questo modello.

Answer 2

Il tuo livello di business sicuramente non vuole sapere di righe di dati - cercare di lasciare i dati classi specifiche nel livello dati. Questo riduce accoppiamento e si libera di cambiare il vostro livello di persistenza in un secondo momento, senza all'ingrosso ri-architecting.

Per risolvere il problema specifico, è possibile:

• Crea oggetti dati / entità di base nel vostro livello di dati e li mano fuori al vostro livello di business per il consumo.
• Oppure, come sembra che si sta facendo, creare DTOs (trasferimento dati Objects) che esistono unicamente come mezzo di trasferimento di dati dal livello di dati per una più ricca implementazione del vostro oggetto di business in un livello superiore. Si potrebbe fare questo come parte di uno schema repository in un ricco modello di dominio.

L'altra cosa che si potrebbe desiderare di pensare è Tiers v strati - si fa la differenza come si pensa a queste cose. Tiers sono generalmente fisica, in altre parole che definiscono i confini tra processi. I livelli sono generalmente logico, si separano le funzionalità di un programma in unità debolmente accoppiati. Si sono intesi per i livelli in questo caso.

Answer 3

Se si creano le interfacce alle classi DAO e metterli all'interno del vostro livello di business, è possibile fare riferimento il vostro livello di business dal livello di accesso ai dati. Le classi DAO nella restituzione dei dati di livello oggetti dal livello aziendale.

Il tuo livello di business fa riferimento alle interfacce invece che fare riferimento direttamente gli oggetti di accesso ai dati. l'iniezione di dipendenza attraverso un contenitore CIO (come il castello di Windsor, per esempio) vi permetterà di realizzare questo.

Questa tecnica è chiamata separato interfacciato ed è descritta qui:

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

La migliore spiegazione di questa tecnica che ho visto può essere trovato 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

In questa regola che ogni strato deve disaccoppiati a strato superiore, aggiungendo BL riferimento a DAL non è buona idea. Il suo meglio definire modello di dati in DAL con un'interfaccia e fare affari modulo entità in BL. come le mie esperienze, è meglio utilizzare repository in DAL e l'accesso in nel vostro entità aziendale o Business Process.