Здравствуйте, такая ситуация:
Хочу отдельно сущности (POJO) с бизнес логикой, отдельно персист на основе Hibernate. Так чтобы логика могла обращаться к персисту по вопросам CRUD. С простыми операциями все решается, но у меня возникают ситуации, когда перед сохранением сущности нужно выполнить ряд действий с целью вычисления некоторых из ее свойств и проверки на возможность сохранения. При этом в процессе выполнения действий могут быть получены из базы/созданы другие сущности и они так же должны быть сохранены (в случае успешной проверки). Вопрос: куда мне приткнуть эти проверки и действия? сделать их методами самой сущности? не могу потому что проверка+создание других сущностей+запись должны выполняться в одной транзакции, а прямой доступ к сессиям и транзакциям из логики делать я не могу. Вынести отдельно - ну все-таки это личное дело сущности, как проверять и что делать перед записью, получается некрасиво.

Petro123, Blazkowicz , большое спасибо за ликбез и ссылки. Теперь, если можно, давайте на примере. Я придумал пример приложения, которое описывает мою проблему.
Есть благотворительное общество "ЖОР", производящее и бесплатно предоставляющее конфеты "Драже красное" и "Драже зеленое" (всего два вида) для детей из неблагополучных семей в любых количествах. "ЖОР" предоставляет конфеты в ящиках. В каждом ящике два отсека, по одному для каждого вида драже. Емкость отсеков, их соотношение и размер ящиков могут быть изменены произвольно по желанию "ЖОР". И есть группа добрых людей "Детолюбы" , в свободное от работы время упаковывающие конфеты в мешки, и непосредственно раздающие детям. Единственное требование "ЖОР" - чтобы на мешках с конфетами были напечатаны номера ящиков, из которых взяты конфеты. Каждый мешок может содержать конфеты только одного вида. Процедура упаковки такая: "Детолюб" смотрит, есть ли у него в ящиках конфеты нужного вида. Если есть, насыпает в мешок сколько нужно и ставит печать с номером ящика, если не хватает, берет следующий ящик и сыпет из него. Если у него закончились ящики, идет в "ЖОР" и берет новый, и так пока не заполнит мешок конфетами. Мешки, кстати, тоже разного размера все. Таким образом, после упаковки мы имеем мешок с конфетами, на котором один или несколько штампов с номерами ящиков. Может случиться так, что "ЖОР" откажется предоставить очередной ящик с конфетами, таким образом не будет достаточно конфет чтобы заполнить мешок. Тогда "Детолюб" должен высыпать из мешочка то что он туда уже насыпал обратно в те ящики, из которых брал. "Детолюб" никогда не может взять ящик "про запас". Только для того чтобы положить оттуда в мешок что-нить. Если вдруг ребенок вернет мешок с конфетами, "детолюб" обязан высыпать все в ящики из которых брал, и если один из ящиков окажется полным, немедленно вернуть его в "ЖОР", и попросить следующий только когда он реально понадобится.

Вот такая у меня история. Помогите мне, пожалуйста, найти хорошее отражение такой предметной области. Приложение должно автоматизировать деятельность "Детолюба", то есть предоставлять детям мешки с конфетами, и реализовывать описанные алгоритмы его поведения. Нужно использовать хибернейт. Небольшую иллюстрацию прилагаю.

Petro123,
ОК, пишем классы. Чтобы сильно много не писать, немного упрощу и изменю задачу. Ребенок сам приходит к "Детолюбу" и просит его дать ему мешок с конфетами, детолюб записывает пожелание ребенка, и пытается его выполнить - то есть найти конфеты в требуемом количестве. С учетом хибернейта, нарисую сначала статику:


Теперь нужно разобраться, где будет производиться заполнение partList и где будет проверяться, возможно ли выдать нужное количество конфет. Пусть новые Box-ы от "ЖОР" выдает специальный сервис:


Этот сервис заботится о том, чтобы выдать коробку с "ЖОР", иногда может отказать в выдаче и выбросить исключение
Также пусть будет сервис, который выдает список коробок, уже полученных от "ЖОР", из которых уже когда-либо выдавались конфеты:


Теперь можно написать алгоритм обработки, или, насколько я понял, бизнес - транзакции.Пишу прямо здесь, так что может быть море ошибок.


Вот, теперь вопрос, как будет выглядеть та часть программы, которая будет отвечать за сохранение результатов этой транзакции в базу и откат в случае эксепшна? Ведь это чистая логика, я не хочу прямо сюда писать хиберню, но хочу чтобы у меня однозначно выполнилась такая транзакция: в случае успеха(когда конфет хватает) чтобы сохранился сам SweetPack, все новые Box(это самостоятельные сущности), и список частей SweetPack-а. В случае провала - чтобы сохранился только SweetPack, список частей очистился, все новые Box-ы не попали в базу. Кроме того, мне нужна такая штука: если ни у одного SweetPack нет ссылок через их списки на Box, я хочу чтобы этот Box был удален из базы. Уменьшение количества ссылок может происходить при реализации поведения "аля 1С" - когда я сознательно чищу список SweetPack, но не удаляю его самого.

ну и вид конфет пусть один будет, забыл написать

Petro123, меняю постановку. Пусть у меня будет n видов конфет. Тогда классы изменятся следующим образом:

Блин..случайно энтер нажал. Продолжим. process() тоже изменится, но весь его описывать уже не буду. Вообщем получается так, что process() это и есть мой детолюб. Он получает заявку от ребенка - объект SweetPack, и инструкции что делать с этим объектом. А делать он может следующее:
1. Просто запомнить, что ребенок хочет конфет=записать объект с пустым списком partList.
2. Исполнить заявку - то есть записать объект, заполнив его partList - если не получит отлуп от JORService.
3. Принять от ребенка мешок обратно - очистить partList, записать объект.+ проверить, остались ли ссылки на используемые боксы. Если нет - удалить их.
Исходя из этого, можно сказать, что Petro123 Кроме того. "Пошел за ящиком" это тоже подлежит автоматизации)))? подлежит! потому как именно process()-детолюб ходит за ящиком JORService.getBox(). Также из этого следует, что пользователь системы - это ребенок.Он составляет заявку - заполняет каких конфет и сколько он хочет в SweetPack, он определяет что с этим делать, нажимая на кнопки сохранить, выполнить и отмена (пункты 1,2,3) выше.
Вообщем придется добавить в код вот это:


Теперь пункты 1,2,3 подробнее с точки зрения состояний объектов:
1. Сохранение - может применяться как к вновь созданному объекту, так и к полученному от персиста из базы. В первом случае объект просто записывается с пустым списком- process(SAVE) . Во втором - если список пуст, то просто записывается, если же список не пуст, то есть заявка выполнена, придется запускать process(POST) -потом записывать , так как данные могли измениться.
2. Выполнить - тоже как для вновь созданного, так и полученного объекта. при этом вне зависимости от состояния списка выполняется process(POST), потом записывается объект
3. Отмена - только для объекта полученного из персиста, у которого список не пуст. очищается список, объект записывается process(CANCEL)
То есть во всех трех случаях вне зависимости от проверок объект записывается, все варианты относятся только к состоянию списка - то есть заявку от ребенка детолюб примет в любом случае, вопрос сможет ли он ее выполнить, и захочет ли этого сам ребенок. Поэтому эта фраза Petro123Неудача или откат - это вернуть все как было до начала транзакции. Не совсем верна, объект полюбому надо записать, а вот список надо очистить в случае неудачи. Как-то так.
Возвращаясь к баранам 1.С какой стороны прикрутить персист сюда, не мешая его с логикой? 2. Как обеспечить удаление боксов на которые нет ссылок?

Petro123, мы очевидно друг друга не понимаем, по крайней мере я вас не понимаю. Я почти уверен, что плохо объясняю чего хочу. Может быть вариант использования поможет, пытаюсь объяснить его максимально подробно. Я именно его и подразумевал когда писал классы. Все что за рамками этого варианта, оставим.
ВИ1: Новая заявка.

1.Пользователь открывает форму заявки на конфеты.
2.Пользователь вводит желаемое количество конфет и их вид.
3. На форме три кнопки: сохранить, выполнить, отменить. Так как заявка новая, кнопка "отменить" неактивна. Пользователь хочет, чтобы его заявка была выполнена немедленно - и он нажимает на кнопку выполнить, немедленно запуская тем самым процесс выполнения заявки (многострадальный метод process()). Пока выполняется этот метод (выполняется он быстро, менее 5 секунд), пользователь ждет и не имеет возможности жмякать на кнопки.
4-1. Если заявку удалось выполнить, пользователь получает сообщение "заявка выполнена", кнопка "отмена" становится активной, на вкладке формы "информация о заявке" появляются данные об источниках конфет для выполнения заявки. Кроме того, пользователь, занимающийся отчетностью, сможет увидеть выполненную заявку в своих отчетах.
4-2. Если заявку не удалось выполнить, пользователь получает сообщение "заявка не выполнена" с указанием причин отказа, состояние активности управляющих кнопок не меняется, введенные данные сохраняются (то есть пользователь может закрыть форму, съездить в Крым, потом найти уже заполненную форму в списке, открыть и попытаться нажать кнопку "выполнить" снова), вкладка "информация о заявке" содержит пустой список.

Вот еще уточняющие моменты:
Petro123Итак, нафига тебе:
- сохранять состояние процесса между сессиями, помня, что это Веб - запрос 40 миллисекунд = ответ, забыл о нём?
- ты точно хочешь пойти по пути а-ля MTS - "Ваша заявка принята - результаты в Меню-СостояниеОперации"?
-про веб я ни слова нигде не говорил
-про сохранение информации между сессиями тоже (ну если считать сохранение сущности - то говорил, но это обычный персист. Да и что тут сверхъестественного? сохранил я заявку, через месяц открыл посмотрел, как тему в форуме например. Сохранение делал один вызов process() - одна транзакция, второй раз открою - обработкой будет заниматься другой process() -другая транзакция, между ними никакой связи нет)
-я просто хочу знать, как мне описать метод process() системы, выполняющий заявку, чтобы непосредственно в нем не использовать напрямую методы хибернейта.

Пересмотрите предыдущие посты с этой точки зрения, и тогда, я думаю, мы будем смотреть на ситуацию с одного бока. Так что process() - это все-таки детолюб , основная часть системы, обрабатывающая заявку пользователя. Сам по себе, как и живой детолюб, он не имеет состояний. Он переводит из одного состояния в другое саму заявку. То есть process() - это ровно то, чем я заменил живого детолюба. При этом модель получается анемичной в том смысле, что сущность "Заявка на конфеты" не обладает инкапсулированным поведением, за поведение отвечает метод сервиса, которому такая сущность передается входным аргументом. Повторюсь не помню какой раз - моя проблема в том что я не знаю как подружить process() и Hibernate, обеспечив целостность транзакции и не вызывая напрямую методов Hibernate, потому что в process() - моя логика, и я не хочу мешать ее с персистом.

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

Petro123, опять непонятки. Мне надо идти на курсы ясного выражения мыслей наверное. Давайте другую абстракцию попробуем, чтобы слово заявка вас так не смущало.
Вам нужны продукты, у вас есть ребенок. вы можете:
а) написать ему записку "чокупить" и сразу отправить в магазин
б) написать ему записку в понедельник, а отправить с этой запиской в магазин в пятницу.

Petro123==== Нельзя. 1. Отменять нечего. Нельзя навешивать на одно окно (контроллёр) кучу логики с Enable-Disable\Visible
2. Либо кнопка Сохранить, Либо Выполнить - это к Вашим спецам по Визабилити. Они подтвердят.
Что плохого когда на форме есть и сохранить и выполнить и отменить? по-моему это удобно. Это как раз отражает в одном месте все то, что можно сделать с заявкой. Как это будет с отдельно сохранить/выполнить нарисуйте, если не сложно. я плохо себе такое удобство представляю.

Petro123 Зачем вы удлинняете процесс, который можно решить за 0,1 сек?
Да ничего я не удлиняю, просто прикинул сколько он будет выполняться на абсолютном корче при хреновом канале связи. В нормальных условиях пользователь и не заметит времени выполнения.

Petro123А - без заявок, в он-лайне - сразу результат, либо конфеты, либо Отлуп )))
Именно так, но с небольшим уточнением. Приходите вы в ресторан, смотрите меню, и говорите: мне борщ, котлеты, пельмени, графин водки, торт, суши, пиццу и орешки. Официант говорит - ничего нет, приходите завтра(отлуп). И вы приходите, опять листаете меню и начинаете вспоминать, что же вы там заказывали(херово). А надо так: отлуп получили, заказ не получили, но информация о нем осталась, и вспоминать мучительно потом не придется.

Petro123Б - с заявкой. Но тогда нужны механизмы блокирования рессурса для заявки. Разумеется нужны, но только на время выполнения process(),а это быстрый метод. Это во-первых, во-вторых блокировка ресурсов пока за рамками обсуждаемой задачи.

Petro123Пока нет ТЗ на вариант Б, сложно искать техническое решение.
Сначала классы, потом ВИ, теперь ТЗ)). почему сложно искать техническое решение именно для того вопроса который я задаю в каждом посте?

Petro123Я вас понял, но почему нужна именно заявка, а не сразу - результат за 0,1 сек?
ААААА!!!!! -мне результат нужен, мне безуууумно нужен результаааат. НО, если получить его я не могу, я хочу чтобы исходные данные остались в форме и все. Чтобы я мог открыть ее потом, и попробовать получить результат снова, не вводя никаких больше данных

Petro123======== кто сказал что он ждёт? Если вы специально делаете ограничение (неасинхронный процесс), то это одно.
Я вам говорю - он ждет, один поток, никакой асинхронности и точка.(в рамках моего вопроса)


Petro123Аналог жд. билеты. Что оооочень хреново. В одной кассе балеты на вагон есть, в другой - нет.
Согласен, такой проблемы избежать практически невозможно ,с той точки зрения что когда кассир смотрит наличие блиетов - может видеть устаревшую информацию на какой-нить необновленной страничке, но попытка продать/забронировать уже проданное место все вернет на круги своя. так что это мы отнесем к разряду вынужденных неудобств,и (в рамках моего вопроса) это меня абсолютно не беспокоит.

Petro123- ваш Процесс претендует на длинную, либо через состояние, либо через механизмы самого хибера
Это не штатный режим. Да где это он на длинную претендует? С чего вы взяли? Нет у Процесса никаких состояний, нету. Состояние есть у заявки плохое слово, обзовем ее документом, как в 1с, вы ее упоминали, значит знаете как она устроена. Документ в 1с может быть просто сохранен, может быть проведен - у него есть состояния, а у процесса ничего нет - это просто алгоритм "проведения".

Petro123,
Petro1234-1. Если заявку удалось выполнить (АвиаБилет куплен), пользователь получает сообщение "заявка выполнена(АвиаБилет куплен)", кнопка "отмена" становится активной (??? Вернуть Билеты?)
Вот, теперь я понял где я вас запутал, и запутал конкретно. Прощу прощения, пользователь, используя ваши аналогии - это кассир, а не пассажир. И он вполне может отменить продажу билета, если, например, ввел некорректные данные. Впоследствии, он их исправит и выполнит еще раз. Разумеется, не во всех случаях можно редактировать уже выполненные/проведенные/активные (как удобнее) документы/заявки. Но это тоже оффтоп