it-swarm-eu.dev

Jak organizujete své projekty?

Máte nějaký konkrétní styl organizace projektů?

Například v současné době vytvářím projekt pro několik škol zde v Bolívii, takto jsem to organizoval:

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

Jak přesně organizujete svůj projekt? Máte příklad něčeho, co jste zorganizovali a jste hrdí? Můžete sdílet snímek obrazovky z podokna Řešení?

V oblasti uživatelského rozhraní mé aplikace mám potíže s rozhodnutím o dobrém schématu, jak uspořádat různé formy a kam patří.


pravit:

A co organizování různých forem v projektu .UI? Kam/jak bych měl seskupovat různé formy? Jejich uvedení do kořenové úrovně projektu je špatný nápad.

150
Sergio

Při navrhování projektu a rozložení architektury vycházím ze dvou směrů. Nejprve se podívám na navrhovaný projekt a zjistím, jaké problémy s buisness je třeba vyřešit. Dívám se na lidi, kteří to budou používat, a začnu s hrubým designem uživatelského rozhraní. V tuto chvíli ignoruji data a jen se dívám na to, co uživatelé žádají a kdo je bude používat.

Jakmile budu mít základní znalosti o tom, co žádají, určím, jaká jsou hlavní data, která budou manipulovat, a zahájím základní rozvržení databáze pro tato data. Poté začnu klást otázky k definování obchodních pravidel, která data obklopují.

Tím, že začnu samostatně od obou konců, jsem schopen rozvinout projekt takovým způsobem, který roztaví oba konce dohromady. Vždy se snažím udržovat návrhy oddělené tak dlouho, jak je to možné, než je roztavím, ale při pohybu vpřed mějte na paměti požadavky každého z nich.

Jakmile budu dobře rozumět každému konci problému, začnu navrhovat strukturu projektu, který bude vytvořen k vyřešení problému.

Po vytvoření základního rozvržení řešení projektu se podívám na funkčnost projektu a nastavím základní sadu oborů názvů, které se používají v závislosti na typu prováděné práce. Může to být například účet, nákupní košík, průzkumy atd.

Zde je základní rozložení řešení, se kterým vždy začnu. Jak se projekty lépe definují, zdokonalím je tak, aby vyhovovaly specifickým potřebám každého projektu. Některé oblasti mohou být sloučeny s ostatními a podle potřeby mohu přidat několik speciálních.

SolutionName

.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

Rád rozděluji své projekty do vrstev

Tímto způsobem je snazší spravovat cyklické závislosti. Mohu například zaručit, že žádný projekt neimportuje například projekt View (vrstvu) omylem. Také mám sklon rozbít své vrstvy v podvrstvách. Takže všechna moje řešení obsahují seznam podobných projektů:

  • Product.Core
  • Product.Model
  • Product.Presenter
  • Product.Persistence
  • Product.UI
  • Product.Validation
  • Zpráva o produktu
  • Product.Web

Jsou to větší „stavební kameny“ mé aplikace. V rámci každého projektu se logicky organizuji v oboru názvů logičtěji, ale hodně se liší. Pro UI, když vytvářím spoustu formulářů, se snažím přemýšlet v prostorovém dělení a pak vytvořit jmenný prostor pro každý „prostor“. Řekněme, že existuje spousta uživatelských preferencí, ovládacích prvků a formulářů, pro ně bych měl jmenný prostor nazvaný UserPreferences a tak dále.

69
Alex

Organizace projektů

Obvykle se snažím rozdělit své projekty podle jmenného prostoru, jak říkáte. Každá úroveň aplikace nebo komponenty je vlastní projekt. Pokud jde o to, jak se rozhodnu, jak své řešení rozdělit na projekty, zaměřím se na opětovnou použitelnost a závislosti těchto projektů. Přemýšlím o tom, jak budou ostatní členové mého týmu tento projekt používat, a pokud jiné projekty, které vytváříme po silnici, mohou mít prospěch z používání některé součásti systému.

Například někdy stačí mít tento projekt, který má celou řadu rámců (e-mail, protokolování atd.):

MyCompany.Frameworks

Jindy chci rozdělit rámce na kousky, aby je bylo možné importovat jednotlivě:

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

Organizování formulářů

Organizace formulářů v rámci projektu uživatelského rozhraní se po rozšíření projektu opravdu promění.

  • Malý - Jednoduchý Složka formulářů by stačila pro velmi malý projekt. Někdy můžete přeměnit struktury stejně jako můžete jmenovat prostory a dělat věci tak složitějšími, než jaké musí být.

  • Střední až velký - Zde obvykle začínám dělit své formuláře do funkčních oblastí. Pokud mám jednu část své aplikace, která má 3 formuláře pro správu uživatele, a některé, které udržují přehled o fotbalových hrách a skóre, pak budu mít formuláře> Uživatelská oblast a formuláře> hry nebo něco podobného. Opravdu záleží na zbytku projektu, kolik forem mám, na tom, jak jemnozrnný to rozdělím.

Pamatujte, že na konci dne jsou jmenné prostory a složky právě tam, aby vám pomohly uspořádat a najít věci rychleji.


Opravdu, záleží na vašem týmu, vašich projektech a na tom, co je pro vás jednodušší. Navrhuji, abyste obecně vytvořili samostatné projekty pro každou vrstvu/komponentu vašeho systému, ale vždy existují výjimky.

Pokyny ohledně architektury systému viz web společnosti Microsoft Patterns and Practices.

19
Ryan Hayes

Když píšu kód v .NET, existuje jasná tendence mít klastry související funkce. Každá z nich může mít stejné podskupiny. Rád rozděluji hlavní skupiny fyzicky - jednu z nich na projekt VS. Potom logicky dále rozděluji pomocí sestav. Podle tohoto vzorce vypadá jeden z mých současných projektů takto:

  • Wadmt (řešení)
    • 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

Doufejme, že je to pro vás užitečné. Úrovně oddělení mi trvalo nějakou dobu, než jsem na to přišel.

12
Grant Palin

Je dobré mít plán pro organizaci vašich řešení a existuje několik způsobů, jak to udělat. Máme určité funkce, které jsou sdíleny mezi více projekty, což také poskytuje konzistentnost pro naše uživatele. Organizace projektu závisí na tom, co děláme. V jeho jádru budeme mít:

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)

Odtud to opravdu záleží na nastavení. Pokud máme klientskou aplikaci i webové rozhraní (užitečné pro shromažďování výsledků využití ve třídě nebo jiném výzkumu), potřebujeme projekt, který má běžně sdílený kód (tj. Datové objekty, které budou serializovány).

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

Podle potřeby mohou být přidány další dílčí projekty. Jak jsem řekl, opravdu záleží na projektu. Některé projekty jsou opravdu jednoduché a vyžadují pouze základní prvky. Snažíme se bojovat s libovolným oddělením projektu, takže dělení vrstvami opravdu dává smysl. Vrstvy jsou definovány tím, co je třeba sdílet mezi projekty, řešeními nebo co musí být pluginy/rozšíření.

7
Berin Loritsch

Je zajímavé, že tolik lidí zde neuvažuje DRY). V mém životě se stalo, že vývojáři vytvořili adresářové struktury, které kvůli tomu nemohli vytvořit. z adresářů řešení a projektů!

Tady je moje cesta:

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

Když navrhuji svou aplikaci, vždy ji vidím jako moduly s některými závislosti mezi nimi. Když mám na mysli design, pak k jeho vývoji použiji strategii bottom-up. Vyvíjím každý modul a pak nechám je pracovat společně.

No, ty moduly jsou projekty pod mým řešením (obvykle knihovny tříd =). Každý modul má jiný jmenný prostor a svůj vlastní design (obsahující třídy atd.).

Jedním z těchto modulů je [~ # ~] gui [~ # ~] (grafické uživatelské rozhraní).

Také vždy používám nástroj Kontrola revize ke sledování změn v každém projektu. Navrhuji Git . Je to opensource, distribuovaný a zdarma k použití.

2
Oscar Mederos

Pokaždé, když začnu s novým projektem, dostanu širokou specifika toho, co má dělat. To, že mi tento vstup pomůže, tím, že mi poskytuje kontext, proto se do toho pustím a vymyslím nejlepší (nebo nejvhodnější) metodu k dosažení cílů projektu. V této chvíli začnu přemýšlet, v jakých desginových vzorcích mi může pomoci poskytnout zamýšlené řešení. Zde je místo, kde začnu organizovat projekt, s přihlédnutím k návrhovým vzorům, které přijmu pro projekt.

Několik příkladů:

  1. Pokud se projekt pouze vrátí k vytvoření obrazovek vstupních dat. S největší pravděpodobností bych použil vzor MVC.
  2. Pokud bude projekt používán jako náročné uživatelské rozhraní, které nejvíce podporuje násobky platforem, stane se nápomocný desginový vzor MVVM.

Mějte na paměti, že každé z těchto kroků vás nutí uspořádat svůj projekt konkrétním způsobem.

Zde je několik čtení:

. Čisté návrhové vzory .

Návrhové vzory .

Objektově orientovaný design .

Snad to pomůže.

1
El Padrino