Come refactoring di grandi progetti in Visual Studio

Question

Mi imbatto sempre in un problema in cui i miei progetti in Visual Studio (2008) diventano enormi mostruosità e tutto viene generalmente inserito in un progetto di applicazione Web. So di verificare alcune cose open source che tendono ad avere più progetti all'interno di una soluzione, ciascuno con le proprie responsabilità.

Qualcuno ha qualche consiglio su come effettuare il refactoring? Cosa dovrebbe essere in un progetto separato rispetto a parte del progetto web? Puoi indicarmi qualsiasi materiale di riferimento sull'argomento, o è solo qualcosa a cui sei abituato con il tempo?

Answer 1

Organizza il tuo progetto in modo pulito in spazi dei nomi. Gli spazi dei nomi non dovrebbero essere troppo grandi, né troppo piccoli. Ogni spazio dei nomi ha una "interfaccia" pubblica (cioè un insieme di classi pubbliche) e non accede ai dettagli di implementazione interna dello spazio dei nomi da altri spazi dei nomi. Spazi dei nomi diversi di solito si rivolgono a parti diverse di un'applicazione, ad es. avrai spazi dei nomi relativi a UI, business logic, funzionalità di supporto, ecc. Il Framework Design Guidelines ha alcuni buoni suggerimenti su come progettare gli spazi dei nomi.

Quando ritieni che il tuo progetto sia troppo grande, identifica semplicemente insiemi di spazi dei nomi chiaramente correlati tra loro e spostali in progetti separati. Poiché altri spazi dei nomi utilizzano già l'interfaccia pubblica degli spazi dei nomi spostati, il refactoring degli spazi dei nomi in nuovi progetti è semplicemente un'operazione di spostamento dei file.

Answer 2

Iniziare dal basso verso l'alto (le classi più semplici che non dipendono da nient'altro che dal Framework) e vedere se è possibile isolare le dipendenze in unità funzionali. Ad esempio, se si dispone di una serie di classi di dati o di business logic che fanno riferimento l'un l'altro, ma non fanno mai riferimento a nessuna delle classi dell'interfaccia utente, allora si ha un candidato per la suddivisione in un altro progetto. Se non riesci a trovare punti di separazione chiari, hai un problema di progettazione e probabilmente dovresti eseguire alcuni refactoring.

Concordo anche sul fatto che l'uso dei namespace sia un buon punto di partenza. Anche all'interno di un progetto, puoi spesso isolare o minimizzare le dipendenze in un modo che raggruppa naturalmente le classi. Inserirli nella stessa cartella rafforza questo raggruppamento come unità funzionale e può davvero aiutare il povero ragazzo che deve mantenere il proprio codice in futuro. Fidati di me, provo a pensare a quel povero ragazzo perché, in più di un'occasione, quel povero ragazzo è stato io. Era un piccolo conforto che la persona che ha scritto il codice avesse lo stesso nome di me nel momento in cui l'ha scritto.

Answer 3

Controlla il guidance given by the Sharp Architecture project. Il suo MVC ASP.Net ma gli stessi principi si applicano a ASP.NET e ad altri progetti. I ragazzi che hanno messo insieme queste cose sono smart Generalmente uso il loro consiglio come predefinito e solo quando ho una buona ragione.

Il tiering di base che si propongono è

• Un progetto di base per gli oggetti del dominio e interfacce per l'accesso ai servizi esterni (compresa la persistenza).
• A dati progetto che dipende core e implementa tutte le interfacce di accesso persistenza
• Un servizi applicativi progetto per sostenere preoccupazioni a livello di applicazione, come la registrazione o la convalida di accesso. Questo si riferisce solo al nucleo.
• A web progetto che contiene solo visualizzazioni.
• A controller progetto che contiene il codice di avvio e il codice per il coordinamento del livello Web, dominio.

Nel caso di un app asp.net Mi piace usare il pattern MVP, che sarebbe praticamente significherebbe il progetto

• Web detiene tuoi WebForms e codebehinds che dovrebbe contenere solo la quantità minima di codice richiesto per reindirizzare al presentatore. Probabilmente avrai anche bisogno di inserire il tuo codice di bootstrap. Ciò è dovuto a una limitazione di ASP.Net e NON dovresti fare riferimento a nessuna di queste cose dal tuo codebehinds.
• Il progetto di controller è sostituito da un progetto di presentatori. La grande differenza qui è che in qualche modo il presentatore deve essere istanziato dal WebForm piuttosto che il contrario.

Si può anche provare a controllare il ASP.NET MVP project.