Сценарий транзакции Antipattern?

Question

Хорошо, есть аналогичная тема о скрипте транзакции с базой данных NoSQL, но эта проблема касается шаблона в целом. Из того, что я нахожу в скрипте Transaction, он не является объектно-ориентированным. Его принципиальный процедурный код, несмотря на то, что он может использовать объекты в каждой строке своего кода.

Лучшее решение заключается в том, чтобы вместо этого использовать модель домена в сочетании с активной записью или картотекой данных с единицей работы/идентификационной картой/ленивым объектом load/query и т. Д. Сценарий транзакций может быть прост в использовании, но это действительно процедурное программирование, и поэтому его следует рассматривать как антипаттерн в объектно-ориентированном мире.

Как вы думаете? Согласны ли вы со сценарием транзакции, который является антипаттерном? Или у вас есть способ разработки сценария транзакции, который является объектно ориентированным, а не процедурным в маскировке? Я сомневаюсь, что это возможно.

Answer 1

Сценарий транзакции определенно не анти-шаблон.

Из того, что я нахожу в скрипте Transaction, он не является объектно-ориентированным.

Вы правы, это не так. Однако этот факт не делает его анти-шаблоном. Хотя это процедурный подход, действительно, он по-прежнему имеет правильное место в серии шаблонов архитектуры бизнес-логики - вам просто нужно знать, в каком случае лучше всего его использовать, и в этом случае это не так. Проще говоря: если ваш проблемный домен очень прост, то не стоит накладных расходов использовать более сложный шаблон в вашей бизнес-логике.

Или, - как Fowler пишет:

Когда использовать это

слава Transaction Script является его простота. Организация логики таким образом естественна для приложений с небольшим количеством логики, и это связано с очень небольшими накладными расходами либо в производительности, либо в понимании.

Анти-шаблон, о котором вы можете подумать, называется Anemic Domain Model. Это так, когда вы намереваетесь и думаете вы строите модель домена - потому что ваш проблемный домен достаточно сложный для этого, но вы на самом деле в конечном итоге в сценарии транзакций - из-за плохой организации кода/слабого OO.

Answer 2

Это не анти-шаблон. Фактически, большинство корпоративных приложений (все, что я видел) используют сценарий транзакции, а не шаблон модели с богатым доменом.

Активная запись шаблон, о котором вы указали, удобен только в том случае, если у вас есть довольно простое сопоставление объектов домена с постоянными агрегатами хранилища (таблицы РСУБД).

Данные преобразователя что-то вроде ORM (Hibernate и друзей). Если ваша бизнес-логика находится внутри объектов домена, эти объекты должны мутировать себя. На мой взгляд, эта пара логика, которая мутирует состояние (которое присуще, когда вы используете ORM) с самим состоянием.Проще посмотреть внешнюю модель вашего домена и включить бизнес-логику в сервисы (сценарии транзакций). Кроме того, если объем бизнес-логики велик, сложнее найти соответствующий код, когда он разбросаны по доменам (это похоже на то, что ваши сценарии транзакций смешаны вместе).

Но вам не нужно в конечном итоге полностью процедурный подход, так как вы можете (и должны) разложить свои услуги на автономные высокосвязные «процедурные контейнеры».