Organizzazione della soluzione

Alcuni direbbero che 70 progetti non sono irragionevoli, tuttavia il mio approccio è sempre stato quello di separare i progetti da quelli che potrebbero essere usati da più di un altro progetto.

Non c'è giusto e sbagliato in questa situazione, tuttavia ho visto persone separare il codice in progetti con poco valore, quindi fatelo quando ha senso, dopotutto, potreste separare il codice in cartelle separate (e namespace) ), e non dimenticare che il codice di separazione in un progetto separato è, cosa, un lavoro di 10 minuti?

Direi che per un progetto MVC sarebbe una buona pratica separare il tuo livello del modello in un progetto separato, perché i livelli di persistenza non dovrebbero mai, IMO, essere assorbiti in alcun progetto di visualizzazione (UI). Potresti fare lo stesso anche per il livello Controller, non sarebbe male avere 3 progetti, ma sarebbe piuttosto improbabile che il livello Controller venisse riutilizzato, ho sempre pensato che View & Il controller era quasi tutto il tempo strettamente vincolato, in cui, come il tuo livello del modello, poteva essere riutilizzato da un altro sito Web, ad esempio un'applicazione per Windows o console.

My 0.02p

Tendo a posizionare il codice dell'interfaccia utente in un assembly separato. Quindi ci sarebbe un assembly MVC o Web o Win a seconda della mia implementazione. Il bit condiviso della soluzione che avrei inserito in un assembly separato. Lo dividerei ulteriormente solo se è veramente necessario; altrimenti uso solo le cartelle.

Separare l'accesso ai dati potrebbe essere necessario se si finisce per utilizzare un altro tipo di archivio dati. Ma, ancora una volta, lo farei solo quando sarà necessario.

Non è necessario separare i modelli o i controller. Per un'architettura plug-in, puoi guardare Controller / Modelli / Viste in assembly separati, ma ciò richiederebbe un po 'di riflessione.

L'unica cosa di cui bisogna guardarsi è un accoppiamento stretto quando tutto è nello stesso assembly poiché tutto è raggiungibile.