it-swarm.it

Come organizzi i tuoi progetti?

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.


Edit:

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.

150
Sergio

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 modo da fondere insieme 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 avanza.

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.
109
Amy Patterson

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.

69
Alex

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. Per quanto riguarda il modo in cui decido come suddividere la mia soluzione in progetti, mi concentro su riusabilità e 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 Forms 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 i miei moduli 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 Moduli> Utente e un = Moduli> Giochi area 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 ad 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, vedere sito Patterns and Practices di Microsoft.

19
Ryan Hayes

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.

12
Grant Palin

È 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 classe 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 del progetto, quindi 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.

7
Berin Loritsch

È interessante notare che così tante persone non considerano 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ò. Mantenere il nome del progetto soluzione fuori e directory di progetto!

Quindi ecco la mia strada:

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

Quando sto progettando la mia applicazione, la vedo sempre come moduli con alcuni dipendenze tra di loro. Quando ho in mente un design, uso una strategia bottom-up per svilupparlo. Sviluppo ogni modulo e quindi li faccio lavorare insieme.

Bene, quei moduli sono progetti sotto la mia soluzione (di solito librerie di classi). Ogni modulo ha un diverso namespace e un suo design (contenente classi, ecc.).

Uno di quei moduli è il [~ # ~] gui [~ # ~] ( Graphic Interfaccia utente).

Inoltre uso sempre uno strumento Revision Control per tenere traccia delle modifiche in ciascun progetto. Suggerisco Git . È open source, distribuito e gratuito da usare.

2
Oscar Mederos

Ogni volta che inizio un nuovo progetto ottengo un'ampia descrizione 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 avrei usato 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 .

Design Patterns .

Design orientato agli oggetti .

Spero che sia di aiuto.

1
El Padrino