Come organizzi i tuoi progetti? [chiuso]

Hai uno stile particolare di organizzazione dei progetti?

Ad esempio, attualmente sto creando un progetto per un paio di scuole qui in Bolivia, ecco come l'ho organizzato:

TutoMentor (Solution)
TutoMentor.UI   (Winforms project)
TutoMentor.Data (Class library project)

Come organizzi esattamente il tuo progetto? Hai un esempio di qualcosa che hai organizzato e di cui sei orgoglioso? Puoi condividere uno screenshot del riquadro Soluzione?

Nell'area dell'interfaccia utente della mia applicazione, ho difficoltà a decidere un buon schema per organizzare diversi moduli e dove appartengono.

Modificare:

Che ne dici di organizzare diverse forme nel progetto .UI? Dove / come dovrei raggruppare forme diverse? Metterli tutti al livello principale del progetto è una cattiva idea.

Quando disegno un progetto e definisco l'architettura, parto da due direzioni. Per prima cosa guardo il progetto in fase di progettazione e determina quali problemi aziendali devono essere risolti. Guardo le persone che lo useranno e comincio con una progettazione dell'interfaccia utente approssimativa. A questo punto sto ignorando i dati e sto solo guardando cosa chiedono gli utenti e chi li utilizzerà.

Una volta che ho una conoscenza di base di ciò che stanno chiedendo, determino quali sono i dati di base che verranno manipolati e inizierò un layout di database di base per tali dati. Quindi inizio a porre domande per definire le regole aziendali che circondano i dati.

Partendo da entrambe le estremità in modo indipendente, sono in grado di delineare un progetto in un modo che unisce le due estremità. Cerco sempre di mantenere i disegni separati il ​​più a lungo possibile prima di fonderli insieme, ma tengo presente i requisiti di ciascuno mentre avanzi.

Una volta che ho una buona conoscenza solida di ciascuna estremità del problema, comincio a delineare la struttura del progetto che verrà creato per risolvere il problema.

Una volta creato il layout di base della soluzione di progetto, guardo la funzionalità del progetto e ho impostato un set di base di spazi dei nomi che vengono utilizzati a seconda del tipo di lavoro svolto. Potrebbero essere cose come Account, Carrello, Sondaggi, ecc.

Ecco il layout di base della soluzione che inizio sempre. Man mano che i progetti vengono meglio definiti, lo perfeziono per soddisfare le esigenze specifiche di ciascun progetto. Alcune aree potrebbero essere fuse con altre e potrei aggiungerne alcune speciali se necessario.

NomeSoluzione

.ProjectNameDocuments
    For large projects there are certain documents that need to be kept with
    it. For this I actually create a separate project or folder within the 
    solution to hold them.
.ProjectNameUnitTest
    Unit testing always depends on the project - sometimes it is just really 
    basic to catch edge cases and sometimes it is set up for full code 
    coverage.  I have recently added graphical unit testing to the arsenal.
.ProjectNameInstaller
    Some projects have specific installation requirements that need to be 
    handled at a project level.
.ProjectNameClassLibrary
    If there is a need for web services, APIs, DLLs or such.
.ProjectNameScripts (**Added 2/29/2012**)
    I am adding this because I just found a need for one in my current project.  
    This project holds the following types of scripts: SQL (Tables, procs, 
    views), SQL Data update scripts, VBScripts, etc.
.ProjectName
    .DataRepository 
        Contains base data classes and database communication.  Sometimes 
        also hold a directory that contains any SQL procs or other specific 
        code.  
    .DataClasses
        Contains the base classes, structs, and enums that are used in the 
        project.  These may be related to but not necessarily be connected
        to the ones in the data repository.
    .Services 
        Performs all CRUD actions with the Data, done in a way that the 
        repository can be changed out with no need to rewrite any higher 
        level code.
    .Business
        Performs any data calculations or business level data validation,
        does most interaction with the Service layer.
    .Helpers
        I always create a code module that contains helper classes.  These 
        may be extensions on system items, standard validation tools, 
        regular expressions or custom-built items.  
    .UserInterface
        The user interface is built to display and manipulate the data.  
        UI Forms always get organized by functional unit namespace with 
        additional folders for shared forms and custom controls.

Mi piace dividere i miei progetti in livelli

In questo modo è più facile gestire le dipendenze cicliche. Posso garantire che nessun progetto sta importando il progetto View (layer) per errore, per esempio. Tendo anche a rompere i miei strati in sottostrati. Quindi tutte le mie soluzioni hanno un elenco di progetti come questo:

• Product.Core
• Modello di prodotto
• Product.Presenter
• Product.Persistence
• Product.UI
• Product.Validation
• Product.Report
• Product.Web

Sono i "blocchi" più grandi della mia applicazione. Quindi all'interno di ogni progetto organizzo in modo più logico negli spazi dei nomi, ma varia molto. Per l'interfaccia utente durante la creazione di molte forme, provo a pensare in una divisione spaziale e quindi a creare spazi dei nomi per ogni "spazio". Diciamo che ci sono un sacco di preferenze e controlli utente preferenze utente, avrei uno spazio dei nomi chiamato UserPreferences per loro, e così via.

Organizzazione di progetti

In genere cerco di dividere i miei progetti per spazio dei nomi, come dici tu. Ogni livello di un'applicazione o componente è il proprio progetto. Quando si tratta di decidere come suddividere la mia soluzione in progetti, mi concentro sulla riusabilità e le dipendenze di tali progetti. Penso a come gli altri membri del mio team useranno il progetto e se altri progetti che creiamo lungo la strada potrebbero trarre vantaggio dall'uso di alcuni componenti del sistema.

Ad esempio, a volte, basta avere questo progetto, che ha un intero set di framework (e-mail, registrazione, ecc.):

MyCompany.Frameworks

Altre volte, potrei voler dividere i quadri in pezzi, in modo che possano essere importati singolarmente:

MyCompany.Frameworks.Networking
MyCompany.Frameworks.Logging
MyCompany.Frameworks.SomeLOBFramework

Moduli organizzativi

L'organizzazione dei moduli nell'ambito di un progetto UI si trasformerà davvero man mano che il progetto si espande.

• Piccolo : una semplice cartella Form potrebbe essere sufficiente per un progetto molto piccolo. A volte puoi sovrastimare le strutture proprio come puoi fare con gli spazi dei nomi e rendere le cose molto più complicate di quanto debbano essere.

• Medio-grande - Qui, di solito inizio a dividere le mie forme in aree funzionali. Se ho una parte della mia app che ha 3 moduli per gestire un utente e alcuni che tengono traccia delle partite e dei punteggi di calcio, avrò un'area Forms> User e un'area Forms> Games o qualcosa del genere. Dipende molto dal resto del progetto, da quante forme ho su quanto a grana fine lo spezzo.

Ricorda, alla fine della giornata, gli spazi dei nomi e le cartelle sono lì per aiutarti a organizzare e trovare le cose più velocemente.

In realtà, dipende dal tuo team, dai tuoi progetti e da ciò che è più facile per te. Suggerirei che, in generale, realizzi progetti separati per ogni livello / componente del tuo sistema, ma ci sono sempre delle eccezioni.

Per indicazioni sull'architettura del sistema, consultare il sito Patterns and Practices di Microsoft.

Quando scrivo codice in .NET, c'è una chiara tendenza ad avere cluster di funzionalità correlate. Ognuno dei quali può avere alcuni sottoinsiemi dello stesso. Mi piace dividere fisicamente i principali gruppi, uno di questi per progetto VS. Quindi suddivido ulteriormente logicamente usando gli assembly. Seguendo questo schema, uno dei miei progetti attuali si presenta così:

• Wadmt (soluzione)
  • Wadmt.Common
  • Wadmt.Data
    • Wadmt.Data.MySql
    • Wadmt.Data.SqlServer
    • Wadmt.Data.Oracle
  • Wadmt.Domain
  • Wadmt.Services
  • Wadmt.Tests
    • Wadmt.Tests.Common
    • Wadmt.Tests.Domain
    • Wadmt.Tests.Services
    • Wadmt.Tests.Integration
  • Wadmt.Web

Spero che ti sia utile. I livelli di separazione mi hanno impiegato del tempo per capire.

È bene avere un piano per organizzare le tue soluzioni e ci sono diversi modi per farlo. Abbiamo alcune funzionalità condivise tra più progetti, che forniscono anche coerenza ai nostri utenti. L'organizzazione del progetto dipende da ciò che stiamo facendo. Al suo centro avremo:

Company (solution)
  Company.Common (shared library)
  Company.Project (Main application UI)
  Company.Project.UnitTests (Unit tests for all project modules)
  Company.Project.IntegrationTests (integration tests for all project modules)
  Company.Project.AutomationTests (tests that invoke the UI)

Da lì dipende davvero dalla configurazione. Se disponiamo sia di un'applicazione client che di un front-end Web (utile per raccogliere risultati di utilizzo in aula o altre ricerche), abbiamo bisogno di un progetto che abbia il codice comunemente condiviso (ovvero gli oggetti dati che verranno serializzati).

  Company.Project.Model (ORM and business logic layer)
  Company.Project.Webapp (Web frontend/web service layer)
  Company.Project.WebClient (client code for web services)

Altri sottoprogetti possono essere aggiunti se necessario. Come ho già detto, dipende davvero dal progetto. Alcuni progetti sono davvero semplici e richiedono solo elementi chiave. Cerchiamo di combattere la separazione arbitraria dei progetti, quindi la divisione per strati ha davvero senso. I livelli sono definiti da ciò che deve essere condiviso tra progetti, soluzioni o che devono essere plugin / estensioni.

È interessante il fatto che così tante persone non considerino il DRY qui. È successo alcune volte nella mia vita che gli sviluppatori hanno creato strutture di directory che non sono state in grado di costruire a causa di ciò. Tieni il nome del progetto fuori dalla soluzione e dalle directory del progetto!

Quindi ecco la mia strada:

{drive}:\{customer}\{apps|libs|tools}\{project}
  - cer
  - res
  - src
   - Common
   - Data
   - UI
   - Logic
   - Logic._Tests  

Quando progetto la mia applicazione, la vedo sempre come moduli con alcune dipendenze tra di loro. Quando ho in mente un progetto, uso una strategia dal basso per svilupparlo. Sviluppo ogni modulo e poi li faccio lavorare insieme.

Bene, quei moduli sono progetti sotto la mia soluzione (di solito librerie di classi ). Ogni modulo ha uno spazio dei nomi diverso e un proprio design (contenente classi , ecc.).

Uno di questi moduli è la GUI ( Graphical User Interface ).

Ho anche sempre usare un controllo di revisione strumento per tenere traccia delle modifiche in ogni progetto. Suggerisco Git . È open source, distribuito e gratuito da usare.

Ogni volta che inizio un nuovo progetto ottengo un'ampia specifica di ciò che dovrebbe fare. Avere questo contributo mi aiuta fornendo un contesto, quindi vado avanti e penso al metodo migliore (o più appropriato) per raggiungere gli obiettivi del progetto. A questo punto comincio a pensare a quali schemi desgin potrebbero aiutarmi a fornire la soluzione desiderata. Qui è dove inizio a organizzare il progetto, tenendo conto dei modelli di progettazione che adotterò per il progetto.

Un paio di esempi:

1. Se il progetto si riferisce solo alla creazione di schermate dei dati di input. Molto probabilmente userei un modello MVC.
2. Se il progetto verrà utilizzato come interfaccia utente pesante che supporta la maggior parte delle piattaforme multiple, un modello di progettazione MVVM diventa utile.

Tieni presente che ognuno di questi ti costringerà a organizzare il tuo progetto in un modo specifico.

Ecco alcune letture per te:

.Net Design Patterns .

Modelli di design .

Design orientato agli oggetti .

Spero che sia di aiuto.