Come dovrei strutturare una soluzione per un progetto a lungo termine? [chiuso]

Naviga le tue risposte
3

Sto per creare un dashboard di tipo do-everything per il mio team e sto ancora riflettendo sul mio progetto / struttura della soluzione. Poiché questo potrebbe essere un progetto a lungo in corso, voglio ottenere la struttura sin dall'inizio.

Questo è quello che avevo in mente:

  1. Crea una soluzione denominata "doEverythingDashboard"
  2. Elimina il progetto denominato "doEverythingDashboard" sotto la soluzione "doEverythingDashboard"
  3. Crea un progetto winform denominato "interfaccia"
  4. Crea progetti di applicazioni per console per ciascuna funzionalità di "doEverythingDashboard"
  5. Fare riferimento a ciascuna applicazione console in "interfaccia"

Ha senso? Avrebbe più senso avere un solo progetto e creare una classe per funzionalità invece di un intero progetto?

    
posta sooprise 26.06.2012 - 16:57
fonte

3 risposte

11

Since this could be a long ongoing project, I want to get the structure right from the beginning

È piuttosto complicato sapere in anticipo quale dovrebbe essere la struttura corretta per una raccolta di codice, specialmente dove il progetto è essenzialmente uno sforzo R & D (per il quale leggi: non hai personalmente costruito un tale sistema prima di 1 ).

Quindi non preoccuparti; invece, PRIMA scrivere un codice, POI guardarlo e considerare come potrebbe essere più ben strutturato. I moderni strumenti di refactoring significano che non avere per farlo bene la prima volta - e chi può dire che c'è sempre un "giusto" per sempre?!

E per quanto riguarda il tuo ultimo punto - crea nuovi progetti (es. assiemi) esattamente quando vuoi creare nuove unità di distribuzione e per nessun altro motivo. Namespaces può fornire perfettamente l'implementazione di divisioni conceptual puramente.


1 questo utilizzo è da Code Complete o PragProg o qualcosa

    
risposta data 26.06.2012 - 17:05
fonte
1

A seconda del tipo di applicazione, è possibile ottenere alcuni suggerimenti sulla struttura del progetto da esempi di progetti open source. Consentitemi di menzionare anche un punto importante, poiché il vostro progetto avanza potrebbe essere necessario modificare leggermente la struttura o aggiungere livelli aggiuntivi a seconda dei requisiti e del design.

Ci sono dei posti in cui puoi guardare alcuni esempi:

risposta data 26.06.2012 - 17:18
fonte
0

Come accennato in precedenza, inizia a scrivere codice. MA, se scendi lungo la rotta TDD, il futuro refactoring sarà molto più semplice.

Tuttavia ci sono alcune cose da tenere a mente. Cerca di tenere separate le parti logiche della tua soluzione, ad esempio non mettere la logica aziendale / di dominio nei livelli di presentazione (moduli Web / Windows) e non accedere al database / repository direttamente dal livello di presentazione / dall'interfaccia utente. A seconda di quanto complessa è la tua soluzione, potresti utilizzare il tradizionale "livello di accesso ai dati", "livello dominio / livello logico aziendale", "livello presentazione" e avere un progetto nella soluzione per ognuno di questi.

Alcune letture di background che potrebbero aiutare ... link

    
risposta data 29.06.2012 - 17:55
fonte

Leggi altre domande sui tag

Dovrebbe // indicato // quando e // quindi i commenti saranno inclusi nei test unitari? 8 bit e 1 byte, è una domanda valida da porre?