ASP.NET MVC con livello di servizio e livello del repository, dove dovrebbero essere definite le interfacce?

Question

Sono in procinto di determinare un'architettura a strati abbastanza semplice per un'applicazione MVC .NET che ha un livello di repository e un livello di servizio. Ho trovato alcuni esempi abbastanza chiari e semplici, in particolare www.asp.net, e alcune domande e risposte qui, ma sto cercando qualcosa che sia un po 'più semplice, adatto a piccole applicazioni, ma che utilizza progetti diversi, per avere l'idea. L'esempio che ho collegato sopra ha il repository e il servizio come classi nello spazio dei nomi dei modelli. Non basta una chiara separazione per essere in grado di illustrarlo correttamente.

Ho un progetto separato per il repository che implementa l'interfaccia irepository. Esiste un progetto separarate per il servizio che implementa iservice e prende un irepository (iniezione del costruttore). Il servizio implementa iService. È sufficiente per questo esempio che il controller istanzia il servizio, non è ancora necessario un contenitore IOC. Pensalo come un passo intermedio per comprendere le migliori pratiche architettoniche, parte di una sequenza che si basa progressivamente per includere l'iniezione di dipendenza e possibilmente più strati.

La domanda è: dove dovrei definire irepository e iservice? Sia il servizio che i progetti di repository devono fare riferimento, ovviamente. Sembra chiaro quindi che dovrebbero essere definiti in un altro progetto a cui si fa riferimento sia i progetti di servizio che di repository. In tal caso, quale sarebbe una buona convenzione di denominazione? Qualcosa di simile a XXXXContracts?

Allo stesso modo, per i modelli di dati passati tra i livelli di presentazione, servizio e repository, è accettabile avere un progetto separato chiamato XXXXMODELS a cui si fa riferimento a tutti i livelli? Comprendo che in alcuni casi i modelli passati tra il livello di servizio e il livello del repository possono differire da quelli passati tra il livello di servizio e il livello di presentazione, ma il principio è lo stesso.

Ho trovato risposte a domande simili qui, ma tendono a coinvolgere un'architettura più complicata di quella che ho delineato qui. Sto cercando di ottenere un'illustrazione davvero semplice e pulita dei due strati che possono essere visti come uno o due sopra riferendosi al livello dei dati e avere una logica aziendale nei controller, tutto qui. So che esiste un argomento forte e valido per andare direttamente alla migliore pratica, ma non tutti sono adatti a fare quel salto in una volta.

Answer 1

introduzione

Questo è qualcosa che ho chiesto anche a me stesso. Una domanda ardente che ho sempre è simile alla tua;

Quale sarebbe una buona convenzione di denominazione?

Come dovrei nominare le cose? Dovrebbero andare in cartelle o progetti?

Dopo aver cercato in giro sospetto che la risposta sia quella Non importa davvero. L'importante è che la tua soluzione ha un'architettura sensata e che tu cerchi di seguire buone pratiche come SOLIDO.

I miei eroi ASP.NET MVC su questo argomento sono Jeffrey Palermo, Steve Smith e Jimmy Bogard.

Architettura di cipolla

Jeffrey Palermo discute una combinazione di vecchie idee ma le riunisce e gli dà il nome visivamente stimolante di Architettura di cipolla (una lettura consigliata). Jeffrey mostra un buon approccio al problema di dove mettere le cose. Spiega che al centro (o in alto) della tua applicazione hai il tuo Nucleo. Questo livello è dove dovresti mettere interfacce come IRepository e IService.

Quasi tutte le tue interfacce dovrebbero andare nel nucleo e tutto il resto (altri progetti) possono fare riferimento al core. In questo modo tutto conosce la struttura scheletrica dell'applicazione senza conoscere i dettagli di implementazione.

Prova ad avere il riferimento al livello dell'interfaccia utente il meno possibile (entro ragione). In una delle mie applicazioni il mio livello di interfaccia utente (MVC) fa solo riferimento al core. Tutto ciò di cui ha bisogno viene iniettato in esso Iniezione di dipendenza.

Steve Smith discute l'architettura della cipolla e idee simili con dimostrazioni in Best practice MVC Solution: una soluzione al problema della soluzione

La mia soluzione

Nelle mie soluzioni MVC ho una struttura tipica come questa:

• Myproject.core
• Myproject.domain
• Myproject.dipendencyiniezione
• Myproject.infrastructure
• Myproject.web
• Myproject.test

Il Nucleo contiene le mie interfacce. Di solito è diviso in cartelle come servizi, modelli, dominio, repository e così via.

Il Dominio Layer fa riferimento solo al core e contiene la mia implementazione. Fornisce molte delle classi concrete per l'astrazione del dominio nel nucleo. Si occupa di molte logiche aziendali, elaborazione, gestione dei comandi, lezioni di manager, implementazioni di servizi concreti e così via. Lo considero uno strato abbastanza interno e quindi fa riferimento al meno possibile.

Il Iniezione di dipendenza Layer contiene il mio pacchetto/framework e i dettagli di implementazione scelti. Lo considero uno strato esterno; Simile all'interfaccia utente o all'infrastruttura e quindi va bene se fa riferimento molto. Non è necessario che questo strato sia un progetto separato e molte persone ti diranno di non farlo. Va bene; Fai ciò che funziona per la complessità del tuo progetto. Mi piace che il mio DI sia la sua cosa. La cosa buona del fatto che sia così separato è che potrei sostituire il framework DI con uno diverso e le cose andrebbero bene. Nessun livello fa riferimento al progetto DI.

Il Infrastruttura Layer contiene informazioni su registrazione, e -mail e accesso ai dati. Conterrà il mio Orm di scelta. Non è roba da business-logic e non sono cose dell'interfaccia utente. È la ferrovia della mia soluzione per fare le cose. È sullo strato esterno ma fa solo riferimento al nucleo.

Il ragnatela Layer è il mio progetto MVC e fa riferimento solo al nucleo.

Complessità e pensieri finali

Ho trovato risposte a domande simili qui, ma tendono a coinvolgere un'architettura più complicata di quella che ho delineato qui

È un buon punto. È importante tenere a mente la complessità del tuo problema. Ma non essere scoraggiato da buone pratiche di soluzione. La mia soluzione e l'architettura di cipolle non sono necessariamente molto complesse e non si gonfiano davvero la tua soluzione. Mantengono le cose separate.

In Struttura evolutiva del progetto, Jimmy Bogard parla di cose eccessivamente complesse. Se quello che ho detto sembra troppo complesso, segui il consiglio di Jimmy e metti tutto in un progetto (il tuo livello dell'interfaccia utente). Va bene, purché tu ti si adatti.

Ricorda di prendere la mia soluzione solo come idea - qualcosa da considerare; Il mio approccio è un tentativo di seguire i consigli salti dal meglio, ma sono sicuro che ci sono riuscito solo così tanto; Posso (e devo) ancora migliorare.