2012-01-30 17 views
14

All'interno di una singola soluzione di progetto che introduce Aree quando si dispone di molti controller migliora la separazione e consente ai moduli di essere facilmente copiati dentro o fuori la soluzione. Tuttavia, in una soluzione aziendale di grandi dimensioni, preferirei suddividere la logica in progetti separati.Aree MVC per aziende: buone o cattive?

Quindi con progetti UI, Controller, SOA, modello e repository separati. In questo scenario le aree non hanno più senso, in più aggiungono un ulteriore livello superiore all'URL che spesso non è necessario, anche se credo che si possa omettere l'area nell'URL se si mantengono i controller univoci, ma non lo è che un po 'puzzolente?

Forse Le aree sono adatte a siti di media complessità o quando il codice del modulo è meglio conservato in un'unica posizione in modo che possa essere copiato su altri siti o rimosso.

+1

Forse questo può essere di qualche interesse: http://stackoverflow.com/questions/6656843/how-to-reuse-areas-controllers-views-models-routes-in-multiple-apps-or-websi. Ti permetterebbe di separare il tuo codice su più progetti. –

+0

Penso che quello che stai cercando siano le aree portatili, non quelle normali. –

risposta

13

Non sono sicuro che sia la domanda giusta. Le aree possono essere eccessive per piccoli progetti, ma è difficile immaginare un progetto non banalmente grande che non utilizzi aree per mantenere organizzate le classi.

io uso MVC Aree per l'impresa e l'amore parecchie cose su di esso:

  1. In genere le persone stanno lavorando su una caratteristica all'interno di un determinato dominio (ad esempio, la ricerca, Checkout, ecc). Se i nomi delle aree corrispondono ai domini aziendali, le aree MVC consentono di ridurre il tempo necessario per implementare una funzione, poiché le classi correlate sono facili da trovare.
  2. Il routing MVC offre un sacco di flessibilità su come strutturare gli URL. Usavo lo Action Controller "pattern" ma per gli URL non pubblici ho appena abbracciato la rotta predefinita Area per semplificare le cose.
  3. Le aree offrono il netto vantaggio dello stile e, soprattutto, del comportamento di incapsulamento a livello di sezione di sito. Ogni area ha la propria configurazione Web in cui è possibile controllare la pagina di visualizzazione di base o aggiungere gestori gestiti.

Hai assolutamente ragione che i servizi dovrebbero essere in progetti separati/soluzioni del tutto, che astrarre l'accesso ai dati tramite repository, in un ambiente in cui più client possono accedere a funzionalità di business comune.

Ma MVC Areas è in grado di fornire un certo ordine all'interfaccia utente/caos di routing mentre cresce un progetto web che, per me, ha un valore inestimabile, indipendentemente dal contesto.

+0

+1, eccellente panoramica sul perché le aree sono utili. – kprobst

1

In primo luogo, prima di rispondere rispondo che questa è solo la mia opinione e riguarda principalmente i modelli.

Per come la vedo io, le aree possono essere così malvagie ... Se hai molte aree, il tuo solution explorer diventa un labirinto e può essere difficile trovare qualcosa.

Suggerisco di creare un nuovo progetto di libreria all'interno della soluzione e inserire la logica.

Il miglior vantaggio (e non è che si possa trovare quello che stai cercando molto più facile) è che la tua applicazione diventa molto più modulare. Se si crea una libreria e si specifica un riferimento per l'applicazione ASP.NET MVC, non è possibile eseguire in modo semplice e coinvolgere l'interfaccia utente nella logica.

Problemi correlati