Implementazione del contesto limite per l'infrastruttura basata su Entity

Question

Avevo creato un'infrastruttura il nostro nuovo progetto intranet nuovo di zecca e ho cercato di seguire quasi tutte le migliori pratiche. Voglio anche menzionare, questa è la mia prima volta per creare un'architettura da zero.

Attualmente la prima versione della mia infrastruttura è pronta e funzionante. Ma voglio implementare una struttura di contesto limitata alla prossima versione.

Ho cercato di spiegare la situazione attuale seguente.

DbCore: responsabile delle operazioni di dati. Entity Framework 5 Code Utilizzato per la prima volta. Esiste solo una classe DbContext e tutti i DbSet definiti al suo interno. Anche pattern GenericRepository e Unit of Work implementati in base alle seguenti interfacce.

IGenericRepository

public interface IGenericRepository<TEntity> 
    where TEntity : class { 
     void Delete(object id); 
     void Delete(TEntity entityToDelete); 
     System.Collections.Generic.IEnumerable<TEntity> Get(System.Linq.Expressions.Expression<Func<TEntity, bool>> filter = null, Func<System.Linq.IQueryable<TEntity>, System.Linq.IOrderedQueryable<TEntity>> orderBy = null, string includeProperties = ""); 
     System.Collections.Generic.IEnumerable<TEntity> GetAll(); 
     TEntity GetByID(object id); 
     System.Collections.Generic.IEnumerable<TEntity> GetWithRawSql(string query, params object[] parameters); 
     void Insert(TEntity entity); 
     void Update(TEntity entityToUpdate); 
    } 

IUnitOfWork

public interface IUnitOfWork { 
     void Dispose(); 
     IGenericRepository<Test> TestRepository { 
      get; 
     } 
     IGenericRepository<Log> LogRepository { 
      get; 
     } 
     void Save(); 
    } 

Modelli: responsabili modelli di entità memorizzazione per DbCore e Entity Framework Domain: Rappresentare livello di logica di business memorizza anche DTOS per entità oggetti che sono stati memorizzati nel progetto Models. Attualmente la logica di business memorizzati in classe di servizio che ha implementato seguente interfaccia IService classe

public interface IService<TEntity> { 

     IEnumerable<TEntity> Get(); 
     TEntity GetByID(int id); 
     void Insert(TEntity entity); 
    } 

Questo servizio diventa UnitOfWork mediante il parametro ctor e utilizzare per le operazioni. Anche Automapper è stato implementato per convertire oggetti entità in DTO o viceversa. D'ora in poi tutti i livelli superiori non sono più interessati ai modelli di entità, usano solo DTO. Quindi quasi tutti i progetti (inclusi, api e web) fanno riferimento a questo progetto.

Comune: Responsabile per l'archiviazione di librerie di uso comune come la registrazione.

WebCore: Responsabile per l'archiviazione di librerie di uso comune per progetti basati sul Web come API o MVC. Contiene inoltre estensioni, gestori e filtri per progetti basati su MVC.

Api: Il progetto API Web MVC ASP.Net rappresenta il livello di servizio. Consuma il livello del dominio e serve ai client. I controller ottengono l'interfaccia IService come parametro ctor e la usano per accedere al livello dati tramite il livello dominio.

Web: ASP.Net Progetto Web basato su MVC 4, responsabile dell'interazione con l'utente. Consuma metodi Api per accedere ai dati. Tutti i controller ottengono un'interfaccia denominata IConsumeRepository che collega API tramite HttpClient.

public interface IConsumeRepository<TEntity> { 
     Task<TEntity> Create(TEntity TestInfo); 
     Task Delete(int id);  
     Task<IEnumerable<TEntity>> Get(); 
     Task<TEntity> Get(int id); 
     TEntity New();  
     Task<TEntity> Update(TEntity TestInfo, int entityId); 
    } 

Autofac è responsabile per IoC e DI per tutti i progetti.

Per ora questa è la mia infrastruttura attuale, penso di aver spiegato tutto ciò che deve essere valutato.

Ora sto cercando di capire seguenti cose,

Domanda 1: C'è qualcosa NON DEVE essere attuati il ​​modo in cui ho usato?

Domanda 2: Qual è l'approccio migliore per implementare contesti limitati? Di recente ho visto i video di Julie Lerman e ho recensito molti progetti campione. La cosa comune che ho visto derivare BC da DbContext. Ma non potevo esserne sicuro. Perché avevo pensato che BC dovrebbe essere nel livello dominio (business logic) non nel livello DbCore (accesso ai dati).

Domanda 3: Come accennato in precedenza, i miei progetti Api e Web utilizzano DTO in modo che entrambi debbano avere riferimenti Livello dominio. Ma non mi è piaciuto, perché sto separando il livello aziendale dall'interfaccia utente con un'API e li ho accoppiati di nuovo per le entità. Ma non sono riuscito a trovare un modo migliore di questo.

Questa è diventata una lunga domanda, ma sarò molto felice se condividi le tue idee con me per creare un'architettura migliore.

Answer 1

Domanda 1: Supponendo che si disponga di un dominio aziendale complesso e di una logica aziendale significativa, può valere la pena fare lo sforzo in quanto è necessario isolare il livello del dominio dai problemi di infrastruttura. Tuttavia, questo spesso non è il caso. Se perlopiù si spostano semplicemente dati dal database all'interfaccia utente e viceversa, si tratta di operazioni eccessive e si dovrebbe cercare qualcosa con meno parti mobili.

Domanda 2: Quanti diversi modelli di domini (con lingue diverse ubiquitarie) avete? Uno? Due? Tre? Per ogni modello, isolarlo il più possibile da altri modelli e preoccupazioni dell'infrastruttura.

Eric Evans definisce un contesto limitato in primo luogo come un linguistica confine (citazione dal suo libro):

UN CONTESTO delimitata delimita l'applicabilità di un particolare modello così che i membri del team hanno una chiara e comprensione condivisa di ciò che ha essere coerente e in che modo si riferisce ad altri CONTESTI. All'interno di quel CONTESTO , si lavora per mantenere il modello logicamente unificato, ma non preoccuparsi sull'applicabilità al di fuori di questi limiti. In altri CONTEXTS, si applicano altri modelli , con differenze di terminologia, concetti e regole, e in dialetti della LINGUA UBIQUITOSA.

DbContext può puntare nella giusta direzione, ma ricordate che è un infrastrutture artefatto, non un concetto di dominio. Esso "rappresenta una combinazione dei modelli Unità di lavoro e Repository e consente di interrogare un database e raggruppare le modifiche che verranno quindi riscritte nel negozio come unità." _ (Da MSDN Docs).

DDD riguarda la modellazione del dominio: utilizzo di modelli per risolvere problemi aziendali complessi in domini aziendali complessi. Derivare i limiti del modello da considerazioni tecniche può sembrare la coda che scuote il cane. Definire concettualmente il limite del modello, quindi allineare l'infrastruttura tecnica di conseguenza.

Domanda 3: Le DTO possono essere un buon modo per applicare un limite di contesto, ad esempio per un'API. L'API può quindi funzionare come strato anti-corruzione su altri modelli. Il motivo per cui le persone li utilizzano in genere per le interfacce utente è evitare di dover eseguire il sanguinamento dei concetti dell'interfaccia utente nel modello di dominio.

Non cercare un'architettura perfetta. E rendersi conto che le "migliori pratiche" sono in realtà solo linee guida basate su particolari situazioni. Segui le linee guida stabilite da altre persone più esperte, con la consapevolezza che la tua situazione è probabilmente sottilmente diversa. Usa quello che hai con l'aspettativa di refactoring le tue decisioni di progettazione quando trovi l'attrito. Ad esempio, se in seguito si scopre che i DTO dell'interfaccia utente sono eccessivi, quindi rimuoverli. Semplifica ovunque tu possa.