Passaggio di dati tra livello aziendale e livello di accesso ai dati - codice errato?

Question

Sto usando il seguente codice all'interno della classe JCProperty per recuperare dati da un DAL:

Dim x As JCProperty
        x = JCPropertyDB.GetProperty(PropertyID)

        If Not x Is Nothing Then
            Me.PropertyID = x.PropertyID
            Me.AddressLine1 = x.AddressLine1
            Me.AddressLine2 = x.AddressLine2
            Me.AddressLine3 = x.AddressLine3
            Me.AddressCity = x.AddressCity
            Me.AddressCounty = x.AddressCounty
            Me.AddressPostcode = x.AddressPostcode
            Me.TelNo = x.TelNo
            Me.UpdatedOn = x.UpdatedOn
            Me.CreatedOn = x.CreatedOn
            Me.Description = x.Description
            Me.GUID = x.GUID
        End If

Funziona bene ma richiede che l'oggetto DAL (JCPropertyDB) sia a conoscenza dell'oggetto business (JCProperty) e creo e popolerò effettivamente lo stesso oggetto due volte (una volta nel DAL per tornare al BL e poi di nuovo nel BL oggetto di popolare se stesso).

Mi manca qualcosa qui, so che deve esserci un modo migliore!

In effetti devo assegnare 'Me = x' che non è permesso. Qualcuno può mettermi in chiaro?

Answer 1

Personalmente, sono pigro. Di solito faccio qualcosa del tipo:

class JCProperty : inherits JCPropertyDB
   {

   New()
      {
      MyBase.New()

      GetProperty(PropertyID)

      }
   }

Quindi hai praticamente finito, fino a quando non avrai alcune funzionalità aggiuntive nella classe JCProperty che deve accadere "in alto" delle funzionalità già esistenti in JCPropertyDB. Quindi sovrascrivi i metodi JCPropertyDB per chiamare prima il metodo di base, quindi aggiungi la tua nuova funzionalità.

Ron

Answer 2

Ti trovi sulle linee giuste, ma manca un punto leggermente.

In genere, il livello di accesso ai dati (DAL) restituisce Data Transfer Objects (DTO) dal tuo database. Si tratta di semplici oggetti CLR (POCO) semplici che non contengono alcuna logica aziendale, ma semplicemente proprietà che mappano più o meno le tabelle del database.

Avresti quindi un codice che crea un Modello di dominio da questi DTO, indicato come a Mappatore dati . Le classi nel modello di dominio potrebbero avere nomi simili (ad es. CustomerDTO - > Customer) ma oltre ai dati, conterranno regole di validazione e possibilmente altra logica aziendale.

È questo modello di dominio che si utilizza quindi nel proprio livello aziendale, non i DTO effettivi. Ciò significa che se si modificano i DTO restituiti dal DAL (ovvero implementando un nuovo strumento ORM), è necessario modificare il proprio mappatore di dati solo se il modello di dati rimane lo stesso.

Consiglio di guardare Patterns of Enterprise Application Architecture di Martin Fowler per i pattern di accesso ai dati.

Answer 3

Non sono sicuro se questo risponderà alla tua domanda, ma il punto importante è che il modello di dominio è indipendente dalla visualizzazione e indipendente dalla memoria. Questo è spesso indicato come separazione delle preoccupazioni. L'idea è di allentare accoppiamenti e creare un sistema semplice in cui gli oggetti non abbiano diverse responsabilità completamente diverse.
Quindi, ciò che farei è consentire al DAL di creare direttamente oggetti business, ma assicurandomi di non contaminare i miei oggetti business con qualsiasi cosa correlata al DAL. Allo stesso modo non voglio contaminarli con elementi specifici dell'interfaccia utente come HTML. A mio avviso, va bene che sia il livello aziendale, sia DAL sia il livello UI hanno dipendenze dal modello di dominio, tuttavia non va bene avere dipendenze dal modello di dominio e da questi altri componenti.
Per allentare i giunti, utilizzare qualcosa di Spring o qualsiasi altro contenitore di iniezione di dipendenza insieme a interfacce e cavi può aiutarti.
Ricreando lo stesso oggetto in ogni livello, stai violando il principio DRY (non ripetere te stesso) e stai introducendo il codice della piastra della caldaia e aumentando la possibilità di introdurre un errore da qualche parte.

Answer 4

Scopri: http://www.icemanind.com/layergen.aspx

Answer 5

Ho preso BO e rispedito BO dal DAL tramite il modello di bridge e il modello del provider. Non riesco a capire il punto dei DTO se non temevo una pesante serializzazione (ad esempio un servizio Web o JSON). Il mio approccio è stato quello di astrarre il livello dati e il livello aziendale tramite un'interfaccia e fornire un livello dati anonimo inserito nell'oggetto business. Ciò significa che posso collegare qualsiasi livello di dati, implementare un'interfaccia che ha metodi universali Load and Save e che è quindi accessibile tramite il mio livello di dominio. Non esiste un codice DAL nel BL: semplicemente una chiamata a un livello dati fornito e sottratto. La mia chiamata al livello dati è gestita da un modello di provider (nessun riferimento diretto) e lo faccio semplicemente:

public class Person : IBusinessObject<Person>
{
   protected IDataLayer<T> dataLayer;

   Person Load() { this.dataLayer.Load(this); }

}

nel livello dati che ho ...

public class PersonMapper : IDataLayer<Person> 
{
    Person Load(Person person) {
    ...get DB stuff...map to person...decorate object...
       return person;
    }
}

Non so ancora se va bene, ma funziona abbastanza bene per me. Sono riuscito a ottenere un carico lento anche per gli oggetti nidificati usando la riflessione.