Відокремлення бізнес-логіки від DB-логіки з транзакціями

У нашому застосуванні є три шари. Службовий рівень для надання зовнішнього API. BO-шар для нашої логіки бізнесу та DAO-шар для підключення до нашої бази даних.

Скажімо, щоразу, коли ми оновлюємо Файл, ми також хочемо щось змінити в папці, наприклад, "остання змінена дата". Це потрібно зробити в рамках транзакції. Або це вдається, і файл, і папка редагуються. Або стався збій, і транзакція повертається назад, тому обидва об'єкти знаходяться в попередньому стані.

Акція "Редагувати папку, коли файл редагується" - суто бізнес-логіка. Отже, це означатиме, що він належить до шару BO. Однак ми використовуємо Objectify для нашої бази даних, тому для початку транзакції нам потрібно зателефонувати ofy (). Transact (...). Якщо ми називаємо цю функцію в шарі BO, це порушує наш дизайн, оскільки в нашому бізнес-рівні будуть виникати конкретні дзвінки (Datactify) для бази даних.

Що було б чистим вирішенням цієї проблеми?

— Серж Хендрікс
джерело

Не можете FileBOзателефонувати FolderBO.edit(newDate)через проблему транзакцій?

— Виявлено

чи не має Java еквівалент c # TransactionScope?

— Еван

У Java обсяг транзакцій залежить від рамки, яку ви використовуєте. У JEE ним можна керувати сервер додатків, але зазвичай він визначається та керується декларативно vía Frameworks, як Spring (vía анотації, xml, ...)

— Laiv

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

— Мураха P

Відповіді:

Як ви скорочуєте свої транзакції, це справді ділова логіка. Тож дозвольте вашому шару DAO забезпечити незалежний API для db фрейму для transactвказаного вами методу (і, можливо, для таких речей, як commitі rollback). Тоді ви можете використовувати його зі свого рівня BO, не роблячи це залежним від вашої бази даних або db-фрейму.

— Док Браун
джерело

Схоже, що Objectify призначений для атомних транзакцій (транзакцій Google Application Engine ). Він вимагатиме від вас розробити власну абстракцію управління транзакціями .

В цьому випадку. абстракція продовжується Як я делегую управління транзакціями на верхні шари?

Підхід @DocBrown здається мені більш швидким і чистим рішенням для впровадження даної архітектури ( шаруватої архітектури ).

Через те, що ми пропускаємо занадто багато інформації про програму та її контекст, рішення Doc також здається мені найбезпечнішим.

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

Якщо коротко підсумовано, ця схема спрямована на інкапсулювання бізнес-правил у бізнес-операції (одиниці роботи). Шаблон дозволяє успадкувати між B.Ts, і поки я бачу, об’єктивуйте також. Він навіть підтримує композицію. Так або за складом або успадкування, підхід дозволяє складні B.Ts .

Застосований до заданої архітектури, виглядатиме так:

FileService -> FileBO : new EditFileTransaction().execute()
                           |-> ofy().transact(...)
                           |--> FileDAO.actionA()
                           |--> FolderDAO.actionA()
                           |-> [ofy().commit(...)|ofy().rollback()]

— Лаїв
джерело