Jak organizujesz swoje projekty? [Zamknięte]

Czy masz jakiś szczególny styl organizowania projektów?

Na przykład obecnie tworzę projekt dla kilku szkół tutaj w Boliwii, tak go zorganizowałem:

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

Jak dokładnie organizujesz swój projekt? Czy masz przykład czegoś, co zorganizowałeś i z którego jesteś dumny? Czy możesz udostępnić zrzut ekranu panelu Rozwiązanie?

W obszarze interfejsu mojej aplikacji mam problem z wybraniem dobrego schematu do organizowania różnych formularzy i ich miejsca.

Edytować:

Co z organizowaniem różnych formularzy w projekcie .UI? Gdzie / jak powinienem pogrupować inną formę? Umieszczenie ich wszystkich na poziomie głównym projektu to zły pomysł.

Projektując projekt i układając architekturę, zaczynam od dwóch kierunków. Najpierw patrzę na projektowany projekt i określam, jakie problemy biznesowe należy rozwiązać. Patrzę na ludzi, którzy będą go używać i zaczynam od prostego projektu interfejsu użytkownika. W tym momencie ignoruję dane i patrzę tylko na to, o co proszą użytkownicy i kto będzie ich używał.

Kiedy już zrozumiem, o co proszą, określam, jakie są podstawowe dane, którymi będą manipulować, i zacznę podstawowy układ bazy danych dla tych danych. Następnie zaczynam zadawać pytania w celu zdefiniowania reguł biznesowych otaczających dane.

Zaczynając niezależnie od obu końców jestem w stanie ułożyć projekt w sposób, który łączy oba końce razem. Zawsze staram się utrzymywać osobne projekty tak długo, jak to możliwe, przed ich połączeniem, ale pamiętam o wymaganiach każdego z nich, idąc do przodu.

Kiedy już dobrze zrozumiem każdy koniec problemu, zacznę układać strukturę projektu, który zostanie utworzony w celu rozwiązania problemu.

Po utworzeniu podstawowego układu rozwiązania projektu patrzę na funkcjonalność projektu i konfiguruję podstawowy zestaw przestrzeni nazw, które są używane w zależności od rodzaju wykonywanej pracy. Mogą to być np. Konto, koszyk, ankiety itp.

Oto podstawowy układ rozwiązania, od którego zawsze zaczynam. W miarę, jak projekty są lepiej definiowane, udoskonalam je, aby spełniały specyficzne potrzeby każdego projektu. Niektóre obszary mogą być łączone z innymi i mogę dodać kilka specjalnych w razie potrzeby.

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.

Lubię dzielić swoje projekty na warstwy

W ten sposób łatwiej jest zarządzać cyklicznymi zależnościami. Mogę zagwarantować na przykład, że żaden projekt nie importuje projektu View (warstwy) przez pomyłkę. Staram się również rozbijać moje warstwy na podwarstwy. Więc wszystkie moje rozwiązania mają listę takich projektów:

• Product.Core
• Product.Model
• Product.Presenter
• Trwałość produktu
• Product.UI
• Product.Validation
• Product.Report
• Product.Web

Są to większe „bloki konstrukcyjne” mojej aplikacji. Następnie wewnątrz każdego projektu organizuję logicznie w przestrzeniach nazw, ale jest bardzo różnie. W przypadku interfejsu użytkownika podczas tworzenia wielu formularzy staram się myśleć w podziale przestrzennym, a następnie tworzę przestrzenie nazw dla każdej „przestrzeni”. Powiedzmy, że istnieje wiele preferencji użytkownika, formantów i formularzy, miałbym dla nich przestrzeń nazw o nazwie Preferencje użytkownika i tak dalej.

Organizowanie projektów

Zazwyczaj staram się dzielić moje projekty według przestrzeni nazw, tak jak mówisz. Każda warstwa aplikacji lub komponentu jest własnym projektem. Jeśli chodzi o sposób, w jaki decyduję o podziale rozwiązania na projekty, koncentruję się na możliwości ponownego użycia i zależnościach tych projektów. Myślę o tym, w jaki sposób inni członkowie mojego zespołu będą korzystać z projektu, a jeśli inne projekty, które tworzymy w przyszłości, mogą skorzystać z korzystania z jakiegoś elementu systemu.

Na przykład czasami wystarczy mieć ten projekt, który ma cały zestaw ram (e-mail, logowanie itp.):

MyCompany.Frameworks

Innym razem mogę rozdzielić ramy na części, aby można je było importować osobno:

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

Organizowanie formularzy

Organizowanie formularzy w ramach projektu interfejsu użytkownika naprawdę zmieni się wraz z rozwojem projektu.

• Mały - prosty folder Formularze może wystarczyć dla bardzo małego projektu. Czasami możesz przebudować struktury, tak jak możesz przestrzeni nazw i sprawić, że będzie to o wiele bardziej skomplikowane, niż trzeba.

• Średni do dużego - tutaj zwykle zaczynam dzielić swoje formy na obszary funkcjonalne. Jeśli mam jedną część mojej aplikacji, która ma 3 formularze do zarządzania użytkownikiem i niektóre, które śledzą mecze piłkarskie i wyniki, będę mieć Formularze> Obszar użytkownika i Formularze> Obszar gier lub coś w tym stylu. To naprawdę zależy od reszty projektu, ile mam form, jak drobnoziarniste go rozbijam.

Pamiętaj, że pod koniec dnia są dostępne przestrzenie nazw i foldery, które pomagają szybciej organizować i znajdować rzeczy.

To zależy od twojego zespołu, twoich projektów i tego, co jest dla ciebie łatwiejsze. Sugerowałbym, że generalnie tworzysz osobne projekty dla każdej warstwy / komponentu twojego systemu, ale zawsze są wyjątki.

Wskazówki dotyczące architektury systemu można znaleźć w witrynie Microsoft Patterns and Practices.

Kiedy piszę kod w .NET, istnieje wyraźna tendencja do tworzenia klastrów powiązanych funkcji. Każdy z nich może mieć niektóre jego podzestawy. Lubię fizycznie rozdzielać główne grupy - jedną z nich na projekt VS. Następnie dzielę dalej logicznie za pomocą zestawów. Zgodnie z tym wzorcem jeden z moich bieżących projektów wygląda następująco:

• Wadmt (rozwiązanie)
  • Wadmt.Common
  • Wadmt.Data
    • Wadmt.Data.MySql
    • Wadmt.Data.SqlServer
    • Wadmt.Data.Oracle
  • Wadmt.Domain
  • Usługi Wadmt
  • Wadmt.Tests
    • Wadmt.Tests.Common
    • Wadmt.Tests.Domain
    • Wadmt.Tests.Services
    • Wadmt.Tests.Integration
  • Wadmt.Web

Mam nadzieję, że ci się przyda. Poziom separacji zajął mi trochę czasu, aby się zorientować.

Dobrze jest mieć plan organizacji swoich rozwiązań, a jest na to kilka sposobów. Mamy pewną funkcjonalność, która jest wspólna dla wielu projektów, co zapewnia również spójność dla naszych użytkowników. Organizacja projektu zależy od tego, co robimy. U jego podstaw będą:

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)

Stamtąd tak naprawdę zależy od konfiguracji. Jeśli mamy zarówno aplikację kliencką, jak i interfejs internetowy (przydatne do zbierania wyników użytkowania w klasie lub w innych badaniach), potrzebujemy projektu, który ma wspólny kod (tj. Obiekty danych, które będą serializowane).

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

W razie potrzeby można dodać inne podprojekty. Jak powiedziałem, to naprawdę zależy od projektu. Niektóre projekty są naprawdę proste i wymagają jedynie podstawowych elementów. Staramy się zwalczać arbitralną separację projektów, więc podział na warstwy naprawdę ma sens. Warstwy są zdefiniowane przez to, co musi być współużytkowane przez projekty, rozwiązania lub co musi być wtyczkami / rozszerzeniami.

To ciekawe, że tak wielu ludzi nie uważa tutaj SUCHEGO. Zdarzyło mi się kilka razy w życiu, że programiści stworzyli struktury katalogów, których z tego powodu nie udało się zbudować. Trzymaj nazwę projektu poza katalogami rozwiązań i projektów!

Oto moja droga:

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

Podczas projektowania mojej aplikacji zawsze widzę ją jako moduły z pewnymi zależnościami między nimi. Kiedy mam na myśli projekt, używam strategii oddolnej do jego opracowania. Opracowuję każdy moduł, a następnie współpracuję.

Te moduły są projektami w moim rozwiązaniu (zazwyczaj biblioteki klas ). Każdy moduł ma inną przestrzeń nazw i swój własny projekt (zawierający klasy itp.).

Jednym z tych modułów jest GUI ( graficzny interfejs użytkownika ).

Zawsze też używam narzędzia kontroli wersji do śledzenia zmian w każdym projekcie. Sugeruję Git . Jest otwarty, rozproszony i darmowy.

Za każdym razem, gdy zaczynam od nowego projektu, otrzymuję szczegółową specyfikację tego, co powinien zrobić. Posiadanie tego wkładu pomaga mi w zapewnieniu kontekstu, dlatego zaczynam i myślę o najlepszej (lub najbardziej odpowiedniej) metodzie osiągnięcia celów projektu. W tym momencie zaczynam zastanawiać się, w których wzorcach desgin może pomóc mi zapewnić zamierzone rozwiązanie. Tutaj zaczynam organizować projekt, biorąc pod uwagę wzorce projektowe, które przyjmę do projektu.

Kilka przykładów:

1. Jeśli projekt dotyczy tylko budowania ekranów danych wejściowych. Najprawdopodobniej użyłbym wzoru MVC.
2. Jeśli projekt ma być używany jako interfejs użytkownika o dużej wytrzymałości, który w większości obsługuje wiele platform, pomocny jest wzorzec deskrypcji MVVM.

Pamiętaj, że każde z nich zmusi cię do zorganizowania projektu w określony sposób.

Oto dla ciebie lektura:

Wzory projektowe .Net .

Wzory projektowe .

Projektowanie obiektowe .

Mam nadzieję że to pomoże.