Як ви організовуєте свої проекти? [зачинено]

Чи є у вас певний стиль організації проектів?

Наприклад, зараз я створюю проект для декількох шкіл тут, у Болівії, ось як я його організував:

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

Як саме ви організовуєте свій проект? У вас є приклад того, що ви організували і чим пишаєтесь? Чи можете ви поділитися скріншотом панелі рішення?

У області інтерфейсу моєї програми у мене виникають проблеми з визначенням гарної схеми організації різних форм і місця їх належності.

Редагувати:

Що щодо організації різних форм у проекті .UI? Де / як я повинен групувати різні форми? Внести їх у кореневий рівень проекту - це погана ідея.

При розробці проекту та плануванні архітектури я починаю з двох напрямків. Спочатку я дивлюся на проект, який розробляється, і визначаю, які проблеми вирішення проблем потрібно вирішити. Я дивлюся на людей, які ним будуть користуватися, і починаю із сирого дизайну інтерфейсу. На даний момент я ігнорую дані та просто дивлюся на те, що запитують користувачі та хто буде ними користуватися.

Як тільки я зрозумію, що вони просять, я визначаю, що є основними даними, що вони будуть маніпулювати, і розпочати базовий макет бази даних для цих даних. Тоді я починаю задавати питання, щоб визначити правила бізнесу, які оточують дані.

Починаючи незалежно від обох кінців, я можу скласти проект таким чином, що поєднує два кінці разом. Я завжди намагаюся тримати конструкції окремо якомога довше, перш ніж їх з'єднувати, але майте на увазі вимоги кожного, коли я рухаюся вперед.

Як тільки я добре розумію кожен кінець проблеми, я починаю викладати структуру проекту, який буде створений для вирішення проблеми.

Після створення базового макета проектного рішення я переглядаю функціональність проекту та встановлюю базовий набір просторів імен, які використовуються залежно від типу роботи, яка виконується. Це можуть бути такі речі, як обліковий запис, кошик, опитування тощо.

Ось основний макет рішення, з якого я завжди починаю. У міру чіткішого визначення проектів я вдосконалюю його для задоволення конкретних потреб кожного проекту. Деякі області можуть бути об'єднані з іншими, і я можу додати кілька спеціальних, якщо потрібно.

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.

Мені подобається ділити свої проекти на шари

Таким чином легше керувати циклічними залежностями. Я можу гарантувати, що жоден проект не імпортує проект (шар) View помилково, наприклад. Я також схильний розбивати свої шари на підшари. Тож у всіх моїх рішеннях є список таких проектів:

• Product.Core
• Product.Model
• Product.Presenter
• Продукт
• Product.UI
• Продукт.Валідація
• Product.Report
• Product.Web

Вони є більшими "будівельними елементами" мого застосування. Тоді всередині кожного проекту я організовую в просторах імен більш логічно, але це дуже різниться. Для інтерфейсу користувача при створенні безлічі форм я намагаюся продумати просторовий поділ, а потім створювати простори імен для кожного "пробілу". Скажімо, є купа елементів користувальницьких налаштувань і форм користування, я б мав для них простір імен під назвою UserPreferences тощо.

Організація проектів

Як правило, я намагаюся розділити свої проекти за простором імен. Кожен рівень програми або компонента - це власний проект. Що стосується того, як я вирішую, як розбити своє рішення на проекти, я зосереджуюсь на повторному використанні та залежностях цих проектів. Я думаю про те, як інші члени моєї команди будуть використовувати проект, і якщо інші проекти, які ми створюємо вниз, можуть отримати користь від використання якогось компонента системи.

Наприклад, іноді достатньо лише цього проекту, який має цілий набір фреймворків (електронна пошта, ведення журналів тощо):

MyCompany.Frameworks

В іншому випадку я можу захотіти розбити рамки на шматки, щоб їх можна було імпортувати окремо:

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

Організація форм

Організація форм у рамках проекту інтерфейсу дійсно перетворюється на міру розширення проекту.

• Малий - простої папки Форми може вистачити для дуже невеликого проекту. Іноді ви можете переобладнати структури так, як ви можете простору імен і зробити речі набагато складнішими, ніж вони повинні бути.

• Середній до великого - Тут я зазвичай починаю ділити свої форми на функціональні області. Якщо у мене є одна частина мого додатка, яка має 3 форми для управління користувачем, а також деякі, які слідкують за футбольними іграми та результатами, то у мене з'являться Форми> Область користувача та Форми> Ігрова область або щось подібне. Це дійсно залежить від решти проекту, від кількості форм у мене, наскільки дрібнозернистий я його розбиваю.

Пам'ятайте, що наприкінці дня простори імен та папки є просто там, щоб допомогти вам впорядкувати та швидше знайти речі.

Дійсно, це залежить від вашої команди, ваших проектів та того, що вам простіше. Я б запропонував, щоб ви загалом робили окремі проекти для кожного шару / компонента вашої системи, але завжди є винятки.

Докладні відомості щодо системної архітектури див. На веб-сайті Шаблони та практики Microsoft.

Коли я пишу код у .NET, явна тенденція мати кластери відповідної функціональності. Кожен з яких може мати деякі підмножини одного і того ж. Мені подобається фізично виділити основні групи - одну з них за VS-проект. Потім я логічно підрозділяю за допомогою збірок. За цією схемою один з моїх поточних проектів виглядає приблизно так:

• Wadmt (рішення)
  • Wadmt.Common
  • Wadmt.Data
    • Wadmt.Data.MySql
    • Wadmt.Data.SqlServer
    • Wadmt.Data.Oracle
  • Wadmt.Domain
  • Wadmt.Сервіси
  • Wadmt.Tests
    • Wadmt.Tests.Common
    • Wadmt.Tests.Domain
    • Wadmt.Tests.Services
    • Wadmt.Tests.Iintegration
  • Wadmt.Web

Сподіваємось, це вам корисно. Рівень розмежування знадобився мені певний час.

Добре мати план організації своїх рішень, і існує кілька способів цього зробити. У нас є деяка функціональність, яка ділиться між кількома проектами, що також забезпечує узгодженість наших користувачів. Організація проекту залежить від того, що ми робимо. По суті у нас буде:

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)

Звідси це дійсно залежить від налаштування. Якщо у нас є і клієнтська програма, і веб-інтерфейс (корисний для збору результатів використання в класі або інших дослідженнях), нам потрібен проект, який має загальноприйнятий код (тобто об'єкти даних, які будуть серіалізовані).

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

Інші підпроекти можуть бути додані за необхідності. Як я вже сказав, це дійсно залежить від проекту. Деякі проекти справді прості, і потрібні лише основні елементи. Ми намагаємося боротися з довільним поділом проекту, тому поділ на шари дійсно має сенс. Шари визначаються тим, що потрібно ділити між проектами, рішеннями або якими плагінами / розширеннями.

Цікаво, що стільки людей тут не вважають ДУХУ. Кілька разів у моєму житті траплялося, що розробники створювали структури каталогів, які так і не змогли створити. Захистіть назву проекту від каталогів рішень та проектів!

Тож ось мій шлях:

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

Коли я проектую свою програму, я завжди бачу це як модулі з деякими залежностями між ними. Коли я маю на увазі дизайн, тоді я використовую стратегію знизу вгору для його розробки. Я розробляю кожен модуль, а потім змушую їх працювати разом.

Ну, ці модулі - це проекти під моє рішення (зазвичай бібліотеки класів ). Кожен модуль має інший простір імен та власний дизайн (містить класи тощо).

Один з цих модулів є GUI ( графічний інтерфейс користувача ).

Я також завжди використовую інструмент контролю версій для відстеження змін у кожному проекті. Я пропоную Гіт . Це відкритий, розповсюджений та безкоштовний у використанні.

Кожен раз, коли я починаю новий проект, я отримую широку характеристику того, що він повинен робити. Надання цього вкладу допомагає мені, створюючи мені контекст, тому я продовжую і думаю, що найкращий (або найприйнятніший) метод для досягнення цілей проектів. З цього моменту я починаю думати, в яких моделях дезінфікування може бути запропоноване рішення. Ось де я починаю організацію проекту з урахуванням моделей дизайну, які я прийму для проекту.

Кілька прикладів:

1. Якщо проект стосується лише створення екранів вхідних даних. Швидше за все, я б використовував MVC-шаблон.
2. Якщо проект буде використовуватися як інтерфейс із великим режимом роботи, який більшість підтримує декілька платформ, то MVVM-шаблон набору стає корисним.

Майте на увазі, що кожне з цього змусить вас організувати свій проект певним чином.

Ось кілька читань для вас:

.Net Шаблони дизайну .

Шаблони дизайну .

Об'єктно-орієнтований дизайн .

Сподіваюсь, це допомагає.