Modello di caricamento di entità aziendale

Question

Il progetto a cui sto lavorando sta usando l'architettura di livello n. I nostri livelli sono i seguenti:

• Accesso ai dati
• Logica aziendale
• Entità commerciali
• Presentazione

La logica di business viene richiamata nel livello di accesso ai dati e il livello di presentazione viene richiamato nel livello di logica di business e le entità aziendali sono citate da tutti.

Le nostre entità aziendali corrispondono essenzialmente al nostro modello di dati 1-1. Per ogni tavolo, abbiamo una classe. Inizialmente, quando è stato progettato il framework, non è stata presa in considerazione la gestione dei dettagli master o delle relazioni figlio-genitore. Pertanto, tutta la logica aziendale, l'accesso ai dati e le entità aziendali hanno fatto riferimento solo a una singola tabella nel database. Una volta che abbiamo iniziato a sviluppare l'applicazione è diventato subito chiaro che non avere queste relazioni nel nostro modello a oggetti ci stava gravemente danneggiando.

Tutti i livelli (incluso il database) sono tutti generati da un database di metadati interno che utilizziamo per guidare il nostro generatore di codice sviluppato in casa.

La domanda è qual è il modo migliore per caricare o caricare le relazioni nelle nostre entità. Ad esempio supponiamo di avere una classe persona che ha una relazione master-child con una tabella di indirizzi. Questo viene visualizzato nell'entità aziendale come una proprietà di raccolta di Indirizzi sull'oggetto Persona. Se abbiamo una relazione uno a uno, questo verrebbe mostrato come una singola proprietà dell'entità. Qual è l'approccio migliore per riempire e salvare gli oggetti relazione? Le nostre entità aziendali non sono a conoscenza del livello di logica aziendale, quindi non può essere eseguita internamente quando viene chiamata la proprietà.

Sono sicuro che ci sia una sorta di scalpiccio standard là fuori per farlo. Qualche suggerimento?

Inoltre, un avvertimento è che il livello DataAcess utilizza la riflessione per costruire le nostre entità. Le procedure memorizzate restituiscono un risultato selettivamente basato su una tabella e usando la riflessione popoliamo il nostro oggetto business abbinando i nomi delle proprietà con i nomi delle colonne. Quindi fare join sarebbe difficile.

Answer 1

Consiglio vivamente di leggere il libro Patterns of Enterprise Architecture di Fowler. Ci sono alcuni approcci diversi per risolvere questo tipo di problema che descrive bene, comprese le relazioni tra entità.

Uno degli elementi più convincenti sarebbe il modello Unità di lavoro, che è fondamentalmente un raccoglitore, che osserva le azioni eseguite sulle entità e, una volta terminato con l'azione, raggruppa le chiamate al database appropriate e effettua richiesta al database. Questo modello è uno dei concetti centrali utilizzati da NHibernate , che utilizza un oggetto che implementa IDisposable to segnala la fine del "lavoro". Ciò ti consente di racchiudere le tue azioni in un utilizzo e di far sì che l'unità di lavoro gestisca le azioni per te.

Modifica: informazioni aggiuntive

Questo è un collegamento alla struttura di classe base dell'unità di lavoro ... non è davvero la cosa più eccitante del mondo. Fowler fornisce maggiori dettagli nel suo libro, alcuni dei quali puoi vedere qui . Puoi anche guardare l'oggetto Session di NHibernate come possibile implementazione (sono stato in grado di rintracciare interfaccia ISession ... non sono sicuro di dove si trovi l'implementazione)

Spero che questo aiuti.

Answer 2

Un approccio che ho usato in passato è rendere il tipo di contenitore abbastanza intelligente da recuperare gli oggetti richiesti. ad esempio:

public class Relation<T>
{
  private T _value;

  private void FetchData()
  {
    if( LoadData != null ) {
      LoadDataEventArgs args = new LoadDataEventArgs(typeof(T), /* magic to get correct object */);
      LoadData(this, args);
      _value = (T)args.Value;
    }
  }

  public event EventHandler<LoadDataEventArgs> LoadData;

  public T Value {
    get {
      if( _value == default(T) )
        FetchData();
      return _value; 
    }
    set { /* Do magic here. */ }
  }
}

Quindi lo dichiari sulla tua entità come:

[RelationCriteria("ID", EqualsMyProperty="AddressID")]
public Relation<Address> Address {
  get; set;
}

E sta al caricatore del tipo che dichiara la proprietà Address aggiungere un gestore all'evento LoadData.

Una classe simile implementa IList per darti una relazione uno-a-molti.

Answer 3

Che lingua stai usando? Quello che hai descritto è esattamente quello che fa Entity Framework in .Net. Ma non hai condiviso la lingua che stavi usando e presumo che non desideri riscrivere nessuno dei tuoi datalayer.