Належна практика щодо рішення Visual Studio [закрито]

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

База даних зберігається віддалено на веб-сервері та буде доступна через веб-API (вихід JSON) та захищена OAuth. GUI на передньому кінці робиться у WPF, а бізнес-код у C #.

З цього я бачу різні шари Presentation / Application / Datastore. Буде код для управління всіма аутентифікованими викликами до API, клас для представлення сутностей (бізнес-об'єктів), класи для побудови сутностей (бізнес-об’єктів), частини для графічного інтерфейсу WPF, частини моделей перегляду WPF тощо.

Чи найкраще це створити в одному проекті або розділити їх на окремі проекти?

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

Це залежить від розміру проекту

Ось правила, якими я схильний користуватися

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

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

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

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

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

• Якщо у мене є велика кількість спільних користувальницьких стилів / шаблонів / ресурсів, я створю проект саме для них.

Як зауваження, я помилився зі своїм першим великим проектом WPF і розділив їх, розмістивши Моделі в одному проекті, Перегляди в іншому та ViewModels в третьому. Зараз я можу вам сказати, що це не шлях, оскільки технічне обслуговування стає кошмаром :)

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

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

ІМХО окремо майже завжди краще. Я майже завжди відокремлюю свій рівень даних, якщо проект не на 100% банальний. Причина полягає в тому, що рівень даних, як правило, проходить найчастіше. Рідко ви підключите GUI до декількох шарів даних і очікуєте, що він буде добре працювати. Набагато більш поширений сценарій полягає в тому, що у вас є один рівень даних, і ви хочете, щоб він розподілявся по декількох графічних інтерфейсах (наприклад, ASP.Net, WPF і додаток Silverlight). Дивовижно, коли ви можете просто створити проект рівня даних і помістити цей dll в якості посилання в наступному GUI, який ви будуєте.

Для мене 4 * - це магічне число. Один проект для кожного шару і один проект, який визначає всі інтерфейси / DTO, необхідні для зв'язку між ними.

* 7, якщо порахувати одиничні тести

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

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

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

Це виходить, коли я роблю якусь інверсію залежності, щоб об'єднати всі "контракти", інтерфейси, абстрактні класи, об'єкти передачі даних в одну збірку. В іншій збірці я помістив все, що розмовляє з базою даних. Одиничні випробування отримують власну збірку. Якщо користувальницький інтерфейс є принципово нестабільним (наприклад, формами winfor ASP.NET), то існує значна користь для розбиття інтерфейсу користувача на тестуваний код та нестабільний код - складання кожного. Іноді починає з'являтися якийсь код, який не має нічого спільного з базою даних, інтерфейсом користувача або будь-яким іншим, про який я вже згадував, - це такий код, який я хотів би знаходитись в рамках .NET Цей код я вкладу в збірку утиліт або, принаймні, вкладу його в будь-яку кореневу збірку (можливо, в той, що має інтерфейси).

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

Деякі видання Visual Studio наштовхуються на продуктивність приблизно на 15 збірок, іноді це залежить від проекту. Стратегічне завантаження файлів проектів іноді може допомогти.

Єдина вагома причина мати декілька проектів - це якщо вам потрібно поділитися набором класів і файлів у кількох програмах.

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

Прочитайте цю статтю для більш детального пояснення, чому це так: http://lostechies.com/chadmyers/2008/07/16/project-anti-pattern-many-projects-in-a-visual-studio- файл-рішення /

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