Какова цель менеджеров / Транзакции?
Я создаю пружинное приложение впервые. Я сталкиваюсь с большим количеством проблем с параллелизмом, и я подозреваю, что существует что-то не так со способом, которым я управляю бэкендом. Единственная разница I видит между моим кодом бэкенда и примерами, которые я видел, классы менеджера.
В моем коде у меня есть своя модель (управляемый, в спящем режиме), и мои ДАО к тому же, чтобы сделать CRUD/поиск/и т.д. на моделях. В примере кода я посмотрел на, они никогда не применяют ДАО непосредственно. Вместо этого они используют классы менеджера, которые называют ДАО косвенно. Мне это просто походит на бессмысленное дублирование кода.
Для чего эти классы менеджера? Я считал, что они переносят мой код в "транзакции", но почему я хотел бы это?
3 ответа
Транзакции используются для того, чтобы сделать обновления «транзакционными».
Пример) Пользователь нажимает на веб-страницу, после чего в базе данных обновляются 13 записей. Транзакция обеспечит выполнение 0 или 13 обновлений, ошибка заставит все откатиться.
Менеджеры должны делать дела проще. Они не сделают ваш код потокобезопасным волшебным образом. Прямое использование DAO не является ошибкой безопасности потоков само по себе.
Тем не менее, я предлагаю вам ограничить логику в вашем DAO и поместить как можно больше логики в бизнес-уровни. См. Лучшие практики для шаблона DAO?
Если вы опубликуете небольшой пример своего кода, который плохо работает с несколькими потоками, мы можем предложить некоторые идеи ... но ни транзакции, ни менеджеры сами по себе не исправят ваш проблема.
Многие приложения предъявляют нетривиальные требования, и бизнес-логика часто включает доступ к нескольким ресурсам (например, нескольким DAO), координацию этих обращений и управление транзакциями через эти обращения (если вы обращаетесь к DAO1 и DAO2, вы хотите выполнить фиксацию или откат изменения как неделимая единица работы).
Таким образом, типично инкапсулировать и скрыть эту сложность в выделенных компонентах служб , раскрывающих бизнес-поведение клиентам в крупнозернистой манере.
И это именно то, что делают менеджеры, о которых вы говорите, они составляют уровень обслуживания .
Уровень обслуживания определяет границу приложения [Cockburn PloP] и его набор доступных операций с точки зрения взаимодействия клиентских уровней. Он инкапсулирует бизнес-логику приложения, контролирует транзакции и координирует ответы при реализации его операций.
DAO не должны владеть транзакциями, потому что у них нет возможности узнать, являются ли они лишь частью более крупной транзакции.
Уровень обслуживания - вот где место транзакций. Вы ошибаетесь, говоря, что они являются "бессмысленным дублированием кода"
.