Транзакция script - Антипаттерн?

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

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

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

Ответ 1

Транзакция Script определенно не анти-шаблон.

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

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

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

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

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

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

Ответ 2

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

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

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

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