Як я повинен реалізувати шаблон сховища для складних моделей об'єктів?

Наша модель даних налічує майже 200 класів, які можна розділити на близько десятка функціональних областей. Було б добре використовувати домени, але розділення не є таким чистим, і ми не можемо його змінити.

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

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

По-перше, ви будете пробігати через кожну сутність, яка є, і запитати себе:

Чи має сенс зберігати цю сутність у спокої?

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

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

Можливо, вам слід поглянути на дизайн, керований доменом . Він рекомендує групувати ваші об'єкти в Агрегати та створювати сховища тільки для кореневої сутності кожного агрегата. Це приємний спосіб навести порядок у великій складній об'єктній моделі.

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

Яку теоретичну основу ви знайшли для дизайну баз даних "Шаблон сховища"? Я не здогадуюсь жодного. Це шар складності, що опирається на фальшиве приміщення: що "шар стійкості" - це те, від чого потрібно бути ізольованим. З того, що я можу сказати, це відіграє до широкого ігнорування програмування принципів реляційного дизайну і покладається на передбачувану центральність дизайну ОО програми. Але це не виправдовує його існування на раціональних, не кажучи вже про теоретичних засадах.

Єдиний вірний шлях до дизайну баз даних не змінився за 30 років: проаналізуйте дані. Знайдіть ключі та обмеження та багато стосунків. Створіть свої столи відповідно до нормальної форми Boyce-Codd. Використовуйте представлення даних і збережені процедури для полегшення доступу до даних.

Незважаючи на це, можливо, SQL СУБД забезпечує кращий рівень ізоляції, ніж все, що може запропонувати програміст. Це правда, що в міру зміни бази даних SQL, який використовується для доступу до неї, можливо, доведеться змінити. Але зауважте, що це правда незалежно від того, є чи є посередницький рівень . Поки додаток використовує представлення даних і збережені процедури для доступу до СУБД, звичайні інженерні засоби SQL вказуватимуть, коли зміни базової бази даних визнають недійсними ці представлення та збережені процедури.

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

Хтось із вашої команди безперечно заперечить, що написання SQL для підтримки ваших 200 класів - це велика робота. Без сумніву. Але принаймні це корисна робота. Якщо ви розробляєте базу даних, наслідуючи свій дизайн OO, ви також зробите багато роботи, багато чого буде марним і переможете більшість того, що пропонує вам СУБД.

Наприклад, ви розмірковуєте відображати Блок роботи в базі даних (як я вважаю, таблицю або таблиці). Одиниця роботи є вбудованої службою СУБД: begin transaction... оновлення бази ... commit transaction. Ніщо не моделює, окрім відображення ваших класів у таблиці баз даних у SQL.

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