Чи здатні об’єкти Персистентності невідомі здійснити ліниве завантаження?

Постійність Ігнорування - це застосування принципу єдиної відповідальності, що на практиці означає, що об’єкти домену ( DO ) не повинні містити код, пов'язаний із стійкістю, натомість вони повинні містити лише логіку домену.

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

b) Якщо моє припущення під а) правильне, то DO , скажімо Customer, ніколи не містить методів, таких як GetCustomersабо GetCustomerByID?

c) Якщо мої припущення під пунктами a) і b) є правильними, і якщо припустити, що Customerдоменний об’єкт використовує ледачу завантаження для деяких своїх властивостей, то в певний момент Customerвнутрішня логіка повинна зв’язатися з OC , що, в свою чергу, отримує відкладені дані. Але якщо вам Customerпотрібно зв’язатися з OC, щоб отримати відкладені дані, то ми не можемо реально стверджувати, що об’єкти домену не містять логіки, пов'язаної зі стійкістю ?!

Дякую

ВІДПОВІДЬ ДО jkohlhepp

1) Я припускаю , що OrderProviderі CustomerProviderкласи міститься в бізнес - логіці?

2) З вашої відповіді я розумію, що мої припущення під b) правильні?

3)

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

Але наскільки я можу сказати, щойно доменний код повинен перевірити, чи orderбуло заселене приватне поле, і якщо його немає, звернувшись до OrderProvider, ми вже порушуємо принцип PI ?!

Я вважаю, що ви правильні у своїх припущеннях A і B навколо постійного незнання.

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

Я схильний реалізувати стійкість незнання за допомогою наступних класів:

• Доменні класи - наприклад, Клієнт
• Класи постачальника / сховища - наприклад, CustomerProvider
• Загальні класи запитів до бази даних - наприклад, DatabaseQuery

Клас DatabaseQuery несе відповідальність за використання драйвера бази даних для запиту бази даних та збирання отриманих даних у загальний набір результатів, такий як DataTable. CustomerProvider несе відповідальність за використання класу DatabaseQuery для виконання SQL проти бази даних та використання результатів цього SQL для збирання екземплярів клієнта. Клієнт буде "чистим" об'єктом домену, який містив дані та логіку, пов'язані з клієнтами.

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

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

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

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

У вас просто є клас проводів, який заповнює об’єкти домену (скажімо, щось, що називається "сховище"). Ви можете реалізувати ледачу завантаження або будь-яку схему узгодженості кешу, яку хочете, і об’єкти домену не є мудрішими. Ви розділяєте відповідальність за заселення об'єктів домену від об'єктів домену.