Separazione di problemi e architettura a più livelli in ASP.NET 5 / ASP.NET Core 1

asp.net asp.net-core asp.net-core-mvc dependency-injection entity-framework-core

Domanda

Sto faticando a trovare un modo elegante per mantenere il mio strato DAL separato dal mio livello MVC / UI in ASP.NET 5 grazie alla nuova In Dependency Injection che voglio usare.

Ad esempio, ho un progetto ASP.NET 5, un progetto Business Layer e un progetto di accesso ai dati in cui ho vari codici Entity Framework come entità e contesti. in ASP.NET 5 per ottenere il contesto impostato e il targeting di un database, la documentazione principale suggerisce che faccio qualcosa di simile nella mia classe StartUp.cs

services.AddEntityFramework()
    .AddSqlServer()
    .AddDbContext<BookContext>(options =>
    {
        options.UseSqlServer(Configuration.Get("Data:ConnectionString"));
    });

Ciò significa che ora devo fare riferimento al mio DAL in quello che è fondamentalmente il mio livello di interfaccia utente, qualcosa che per anni è sempre stato una cattiva pratica in base ai vari esperti e post sui blog in giro.

Un modo in cui ho lavorato su questo è creare due nuovi progetti, uno è un progetto CompositeRoot che contiene classi factory per generare le mie classi di business che poi accedono al DAL e anche un progetto Utilities con una classe Configuration in cui è presente una proprietà ConnectionString che posso passare nel mio contesto, quindi utilizzo il comando DI integrato per collegare tutto ed evitare di fare riferimento al mio DAL nel mio livello di interfaccia utente. Ma ho riscontrato problemi con l'ultima versione di Entity Framework (beta 7) poiché ora non sembra possibile specificare una stringa di connessione nel costruttore del contesto o nel metodo OnConfiguration sovrascrivibile. Inoltre, tutta la documentazione finora non sembra interessata a questo mix di preoccupazioni. È questo il modo in cui facciamo le cose ora? Credi che gli sviluppatori non faranno cose "cattive" come le classi di riferimento DAL nell'interfaccia utente direttamente? O c'è un modello che le persone stanno impiegando per mantenere le cose SOLID con questo nuovo costruito in DI / configurazione per ASP.NET 5?

Risposta popolare

Se chiedi a 10 architetti civili di costruirti un ponte, finirai per avere 10 diverse architetture. Nessuno sarà uguale e nessuno sarà migliore dell'altro.

Indipendentemente dal modo in cui si applicano le migliori pratiche e i modelli di progettazione, ciascun architetto giustifica la propria idea. Alcuni saranno troppo zelanti mentre altri lo manterranno semplici e completeranno il lavoro. Tra le altre cose, il budget, le date di consegna e l'artigianato avranno un impatto diretto sul tipo di architettura che deciderà.

La stessa regola vale per gli architetti del software.

Ho visto la mia giusta dose di architetti con le migliori intenzioni al mondo solo per rendermi conto che lo strato UI ha una dipendenza dal DAL. Forse il ragionamento dietro questo è questo:

  • Non ci hanno pensato
  • A loro non importa davvero
  • Facilita la DI poiché vedi ogni livello che a sua volta facilita la mappatura delle Interfacce alla loro Implementazione.

Tornando in MVC 5, avevo i seguenti livelli:

-Contoso.Core (Class Library)
-Contoso.Data (Class Library)
-Contoso.Service (Class Library)
-Contoso.Web (asp.net MVC 5)
-Contoso.Web.Configuration (Class Library)

Il livello Web.Configuration aveva una dipendenza da Core , Data e Service . Questo strato è dove vorrei configurare la mia roba DI.

Il livello Web non aveva una dipendenza dal livello Data e per iniziare, stavo usando il pacchetto Bootstrapper Nuget .

Forse potresti ottenere qualcosa di simile con ASP.NET 5

Mi piacerebbe che Microsoft (o chiunque altro) creasse un modello di progetto di lavoro più orientato verso campioni di livello enterprise utilizzando un approccio disaccoppiato o addirittura qualcosa come un esempio di Architettura di Onion.

Alla fine, qualunque cosa consideri un'architettura ragionevole disaccoppiata potrebbe essere troppo per qualche tempo non abbastanza per gli altri ...

Sentiti libero di condividere le tue scoperte poiché sono curioso di sapere come sei riuscito a farlo funzionare.



Related

Autorizzato sotto: CC-BY-SA with attribution
Non affiliato con Stack Overflow
È legale questo KB? Sì, impara il perché
Autorizzato sotto: CC-BY-SA with attribution
Non affiliato con Stack Overflow
È legale questo KB? Sì, impara il perché