E 'doppio lavoro creando un componente di accesso ai dati e il componente di business?

Question

Sto progettando la mia prima applicazione a strati che consiste in un Dati, Affari, e uno strato di presentazione.

I miei componenti di business (per esempio, Business.Components.UserComponent) attualmente ha il seguente metodo:

public void Create(User entity)
{
    using (DataContext ctx = new DataContext())
    {
        ctx.Users.AddObject(entity);
        ctx.SaveChanges();
    }
}

mi piace questo disegno. Tuttavia, ho incontrato alcuni esempi online che lo consigliano la seguente implementazione:

public void Create(User entity)
{
    // Instanciate the User Data Access Component
    UserDAC dac = new UserDAC();
    dac.InsertUser(entity);
}

Questo si tradurrebbe nella creazione di un Access Component dati per tutte le entità, ciascuna contenente i metodi di base (creare, modificare, cancellare ... ecc).

Questo mi sembra un doppio lavoro da quando ho dovuto creare il Data Access Components con i metodi di base, così come componenti di business che proprio chiama semplicemente i metodi della Data Access Component.

Che cosa sarebbe considerato best practice per dare corretta attuazione alle funzionalità CRUD di base in un'applicazione a strati? Dovrebbero essere 'codificato' nel Component Business o in un Data Access Component?

Answer 1

Dipende. Se vi aspettate che il vostro livello di business semplicemente fare operazioni CRUD di quanto si può seguire il vostro approccio iniziale. Se si prevede di utilizzare una logica un grande business in cui componente di business funziona con molte entità secondo approccio è migliore.

Motivo per cui alla gente piace utilizzare secondo approccio è in test e persistenza ignoranza. Se si utilizza primo approccio il componente di business è strettamente accoppiato con Entity Framework. Mocking ObjectContext non è molto facile compito quindi il test è difficile. Se si utilizza secondo approccio il vostro livello di attività è indipendente sullo strato persistenza. Si può facilmente verificare e si può anche cambiare la persistenza strato se è necessario. Ma questi sono concetti più avanzati che si sta probabilmente non cercando in questo momento. Il tuo codice sarebbe bisogno di qualche ulteriore miglioramento per essere verificabile.

DAC può essere implementato anche come repository. Ci sono molti modi per creare repository generico in modo da avere una sola classe e si definisce il tipo di entità quando instancing repository:

var repository = new GenericRepository<User>();

Anche essere consapevoli del fatto che l'utilizzo di strato di accesso ai dati separata introduce nuova complessità, perché a volte è ragionevole per condividere unico contesto tra i più repository. Questo si trova assieme a qualcosa di noto come Unità di modello di lavoro.

Ci sono un sacco di articoli su attuazione Repository e Unità di modelli di lavoro su Internet. Ho alcuni di loro memorizzate come preferiti a casa in modo Se siete interessati li posso comprendere alla mia risposta in seguito.