GUI, BLL, DAL організація в проекті

Я читаю про шари додатків і хочу використовувати цей дизайн у своєму наступному проекті (c #, .Net). Деякі питання:

1. Чи відбувається розділення шарів через простори імен? Project.BLL. Що б не було, Project.DAL.Що б то не було

2. Чи доцільніше розділити шари, потім компоненти (Project.BLL.Component1) або компоненти, потім шари (Project.Component1.BLL)

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

4. Класи DAL зазвичай статичні? Здається, громіздко створювати об'єкт DAL перед тим, як кожен раз викликати один із його методів.

Будемо вдячні будь-які інші поради щодо правильної роботи з цими шарами.

1. Так. А також збірки.
2. Я розділяв би шари, потім компоненти.
3. Так. До цього існують різні підходи, але я маю IDatabaseService (абстрагуючи різні способи, за якими називається база даних - це майже може бути пряме відображення ExecuteScalar / ExecuteNonQuery / ExecuteReader), а потім різні класи доступу до даних, які розділ за типом даних. Наприклад, у вас може бути клас UserDataAccess, який мав би прості методи CRUD, які створюють / змінюють / видаляють користувацькі об'єкти. Іншим підходом було б мати об’єкт User, в якому вбудований CRUD.

4. Ні. Це значно ускладнює тестовий пристрій. Ви повинні використовувати введення залежності для передачі залежностей конструктору кожного класу доступу до даних (наприклад, IDatabaseService). Потім ви передатимете об'єкти доступу до даних у бізнес-об’єкти, наприклад:

   BusinessObject businessObject = новий BusinessObject (новий DataAccessObject (новий DatabaseService ())); businessObject.PerformOperation ();

Кожному бізнес-об’єкту може знадобитися кілька об’єктів доступу до даних. Ваш код GUI також використовує один або більше бізнес-об'єктів. Деякі об'єкти бізнесу можуть не потребувати жодних об'єктів доступу до даних, але ніколи не повинні використовувати безпосередньо IDatabaseService.

На питання 1 і 2 перейдіть з відповідями Метью.

Я витратив чимало часу, намагаючись зрозуміти найкращий спосіб структурувати DAL настільних додатків. І найкращий спосіб дійсно залежить від потреб програми. В одному зі своїх додатків я пішов дорогою, щоб мати клас DA для кожної таблиці баз даних, який зареєстрував себе центральним (тобто одиночним) класом DataProvider та обробляв CRUD. Кожен клас DA може потім вирішити, хоче він кешувати всі дані таблиці в оперативній пам’яті чи ні (продуктивність!) Та / або чи потрібно мати можливість запускати автоматичні оновлення клієнтів у інших клієнтів, що працюють на інших комп’ютерах (думаю, багатокористувацькі) паралельність). Це дозволяє легко додавати нові класи DAL, оскільки все, що їм потрібно зробити, - це відповідати реєстраційному інтерфейсу.

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

Я б точно не рекомендував будувати CRUD на класах вищого рівня, якщо це не дуже проста програма. DAL - це абстрагування зберігання даних. Якщо ви вирішите змінити сховище даних у якийсь момент у майбутньому (навіть якщо це стосується лише використання MySQL замість MS SQL), ви будете дуже вдячні за це. Плюс: об'єкти BLL повинні бути структуровані за їхніми бізнес-логічними відносинами. DAL-об'єкти структуровані за типом контейнерів для зберігання, які вони представляють. Відмінності можуть бути драматичними.

Як НЕ зробити ваші класи DAL статичним. Що ви отримаєте у швидкості кодування, ви втратите багато разів у доказовості та гнучкості.