2015-02-06 26 views
5

Assumere un progetto Web da ASP.NET MVC 5 e appartenenza OWIN/Identity. L'IoC è fatto con Unity. Tutto è all'interno di un progetto ora. Domanda: Ha senso separare MVC, Idenity e IoC in progetti isolati e incapsulare Identity in qualche IAccountService da risolvere da Unity nel progetto MVC? La domanda sembra essere abbastanza sciocca, ma la mia anatra di gomma tiene il silenzio per ragioni sconosciute, nessuna ipotesi?ASP.NET MVC 5, Identity, Unity architettura soluzione container

L'obiettivo che voglio ottenere un aspetto come questo

ASP.NET MVC (OWIN) -> IOC (Unità) -> AccountServiceImpl -> Identità

Entrambi MVC, IOC -> contratti (IAccountService)

dove -> è un riferimento al progetto

ho bisogno di essere in grado di cambiare contenitore CIO e anche ho bisogno di dati di identità a cui accedere da un altro progetti attraverso un'interfaccia

risposta

5

Sì, è sicuro separare la soluzione in progetti più piccoli come MVC, Identity e IoC.

Almeno, questa è la mia risposta breve.

Ha senso? La lunga risposta è un po 'più complicata. Ho risposto ad alcune domande simili prima dove mi rivolgo soluzione e progetto di architettura:

Nella risposta di cui sopra, ho spiegato

[... ] Ho una struttura tipica come questa:

  • MyProject.Core
  • MyProject.Domain
  • MyProject.DependencyInjection
  • MyProject.Infrastructure
  • MyProject.Web
  • MyProject.Tests

Jeffrey Palermo incoraggia l'uso di Onion Architecture.In part 4 of his article on Onion Architecture, Jeffrey fornisce un example solution con la seguente struttura

  • Nucleo
  • Infrastrutture
  • IntegrationTests
  • UI
  • Unittests

Tuttavia, Jimmy Bogardpo è d'accordo con me e il mio approccio

In Evolutionary Project Structure, Jimmy spiega:

ho usato per la cura di un bel po 'di struttura di progetto in applicazioni. Cercando di applicare la stratificazione logica attraverso progetti fisici, inizierei da un progetto di default per costruire un'app con almeno due progetti, se non di più.

In effetti, Jimmy descrive il suo stile di architettura di soluzione precedentemente preferito come simile allo stile che ho menzionato sopra.

Jimmy va oltre dicendo che "decidere sulla struttura del progetto è uno spreco di tempo ed energia". Preferisce in realtà una struttura di soluzione più semplice. Cioè, molto poco.

Example solution structure

Anche se Jimmy fa chiarire la sua posizione dicendo:

Non ho assolutamente nulla contro di progettazione del software a strati. Usando la struttura del progetto di farlo è una perdita di tempo se hai solo 1 app si sta distribuendo [...]

(enfasi mia)

Se si dispone di altre applicazioni che necessitano di riferimento aspetti della tua soluzione MVC, potrebbe essere molto logico dividerli nei propri progetti in modo da poterli facilmente consultare.

Penso che quello che dovremmo concludere che è:

architettura soluzione non è una regola o una legge. Separare i progetti dove ha senso.

Assicurarsi che la soluzione sia facile da gestire e facilmente comprensibile da altri. Non complicare eccessivamente la tua soluzione.

+0

Grazie mille! Questo è estremamente chiaro! –

+0

Risposta piacevole, sono nuovo di DI e sto cercando di capire l'implementazione. Sto pensando di utilizzare Unity, puoi indicarmi un codice sorgente di esempio con la struttura del tuo progetto. –

2

Aggiungo il mio 0.02 ¢ all'eccellente risposta di Rowan. Dirò di più sull'attuale implementazione di Identity.

Per quanto riguarda il framework ASP.Net Identity, potrebbe essere un po 'complicato spostarlo dal progetto MVC al livello di seduta più alto (o più basso, dipende da come lo si posiziona). Sono abbastanza sicuro che vorresti avere l'oggetto ApplicationUser nel tuo livello dominio.Ma ApplicationUser dipende da IdentityUser che dipende da Identity.EntityFramework, a seconda di EntityFramework. E aggiungere EF al tuo progetto di dominio potrebbe andare leggermente contro le regole di Onion Architecture.

Anche ApplicationUserManager dal framework Identity è enorme (in termini di numero di metodi) e dipende anche da EF. Quindi nasconderlo dietro un'interfaccia può essere complicato.

Quindi, in realtà si hanno 2 opzioni:

  1. prendere un colpo e aggiungere EF nel progetto di dominio e hanno ApplicationUser e ApplicationUserManager classi nel tuo livello di dominio. E non avvolgere UserManager in un'interfaccia per diversi motivi.
  2. Fai un colpo in modo diverso e lascia tutto il materiale Identity nel tuo livello MVC, identifica un insieme molto piccolo di azioni che devi eseguire dal livello Dominio e aggiungi una piccola interfaccia sopra a ApplicationUserManager.

Ho provato entrambi e entrambi gli approcci in diversi progetti ed entrambi funzionano egualmente bene. Ho provato ad aggiungere un'interfaccia in cima a ApplicationUserManager e non sono riuscito - principalmente a causa della dimensione della classe, inoltre è finalizzato a lavorare in modo asincrono e ci sono i wrapper di sincronizzazione. I wrapper di sincronizzazione non funzioneranno con la tua interfaccia, perché la tipizzazione forte.

Ho scritto un blog-post about applying DI to Identity framework e c'è un discussion in the comments sui livelli che si separano - date un'occhiata alle idee.

Problemi correlati