slippery1. Сессия хранит все что мы наделали если ее не закрывать, и в конце при ручном сбросе сохранит все изменения в бд. Так же уже проверил, что если к примеру я сделал выборку какого то элемента, так:
get(A.class, 1);
исправил в нем какое-то поле
и после сделал так:
createQuery("from A").list();
то в результате в списке объектов А будет объект с ид-1 с уже измененным значением поле. То есть хибер заменил объект из выборки на тот что хранится в памяти ну или смержил, внутренностей не знаю.
Я надеялся, что также автоматически хибер сможет убрать и уже удаленные объекты, которые содержатся в сессии со статусом DELETE, то есть если бы я удалил объект А с ид-1:
A a= get(A.class, 1);
remove(a);
createQuery("from A").list()
то в выборке его уже небыло бы, но увы, он там есть....Итак. Тут расскажу только про рабоут сессий. По решению вашей проблемы ниже.
Есть кеш первого уровня. Его скоуп - сессия. В него кладутся все объекты, с которыми вы работали - все, что создали и сохранили, все что вытащили черезе запрос или через load/get.
Теперь внимание - все HQL/SQL запросы, все критерии -
НЕ ИДУТ через кэш первого уровня, они в него не смотрят . Они вытаскивают инормацию сразу из БД и только потом кладут ее в кеш. Поэтому, если вы что-то создали, но не сделали flush(), то нет никакого способа заставить ХИбер вытащить это через HQL запрос. Вообще никак.
slippery2. если идти по первому варианту, мне придется к примеру в
мапе хранить все измененные(добавленные, удаленные, update-сам хибер контролирует судя по эксперименту) объекты, передавать
мап между вкладками. В моем случаи пихать
мап в сессию не нужно так как:
используется zkoss, создается страница и ее контроллер, на страницу помещается компонент типа таббокса в котором и будут вкладки. Вкладки являются отдельными компонентами и помещаться в таббокс будут при создании страницы в зависимости от рассматриваемого объекта. ZKOSS сам поддерживает состояние объекта-контроллера в памяти для запросов от элементов находящихся на странице, то есть если я в контроллере укажу атрибутом какое-то поле, а потом на разных вкладках таббокса будут щелкать кнопки посылающие контроллеру запросы, то класс контроллера будет один и тот же и атрибут с указанным значением будет один и тот же и доступен всем компонентам(в данном случаи вкладкам). Поэтому
мап, сессию или что-там еще могу хранить как атрибуты контроллера(каркаса/визарда) на котором и будут располагаться вкладки.
Далее мне видимо придется при удалении или добавлении объекта на любой из вкладок, помещать его в этот
мап . Ну, а далее мне придется фильтровать все выборки на вкладках руками, то есть получаем на какой-то вкладке
createQuery("from A").list() и проверяем есть ли объекты типа А в
мапе , ага есть, тогда фильтруем выборку, удалим те, что удалены и добавим тех что нет.
Правильно ли я понял вашу идею? Если да, то тут минусы, ладно фильтровать удаленные объекты еще логично и понятно как, но вот добавлять которых нет, уже не совсем ясно, ведь запросы могли быть по условиям, а не простой селект всех из списка, а если по условии то не факт, что в результат выборки нужно добавить все новые объекты получаемого типа из
мапа , может быть только половина подходит.
к примеру на первой вкладке добавили двух пользователей с именами Петя, Вася. А на второй делаем запрос
"найти всех пользователей чье имя начинается на П" тогда в эту выборку нужно добавить только 1 пользователя из
мапа , а не двух.
Как быть в таком случаи????В общем случае в приложении есть слой работы с БД - DAL, есть доменная модель - это часто тупо Entity-бины, есть сервисный слой - это либо те же Entity-бины (Rich Domain Model), либо это отдельные объекты (напр, EJB), которые оперируют над объектами доменной модели. И, наконец, есть слой презентации. Так вот, в общем случае слой презентации не видит доменную модель, он не видит сущностей, он общается с сервисным слоем через определенный интерфейс и получают от него не сущности, а DTO - data transfer object. DTO - это специальные объекты, которые используются только для того, что бы быть переданы клиенты, все.
Итого, мы получаем такую схему:
[СУБД] - [DAL -0 Entity )- SL -0 DTO )- PL]
-0 - это интерфейс
)- - это потребитель интерфейса
То есть, Service Layer обращается к DAL, получает Entity. Presentation обращается к интерфейсам Service Layer, получает DTO. DTO являются моделью, которые рендерятся на веб-странице.
Но это общий случаи, реальность может значительно от него отличаться.
Рассматриваем ваш случаи. У вас он выглядит вот так:
[СУБД] - [DAL -0 Entity )- SL -0 Entity )- PL]
То есть PL общается с SL и получает обратно не готовую модель в виде DTO, а получает сущности. Из этого сразу следует несколько проблем:
1) Вы связываетесь с сессией Хибера.
2) Вам приходится разруливать всякие проблемы с Lazy load.
Что надо сделать, что бы решить эти проблемы? Вам надо полностью отделить PL от Хибера, полностью. Что бы он вообще не знал, что Хибер есть в проекте.
1) Вы вводите слой DTO объектов. С большой вероятностью, они будут повторять структуру ваших сущностей, но в них не будет зависимостей.
То есть вместо сущности Department:
1.
2.
3.
4.
5.
public class Department {
private Long id;
private String name;
private List<Employee> employees;
}
У вас будет вот такой DTO:
1.
2.
3.
4.
public class DepartmentDTO {
private Long id;
private String name;
}
Обратите внимание, что у него нет поля employees. Это сделано сознательно, так как цель это DTO - отрендерить только департамент. При таком подходе вы не сможете выстрелить себе в ногу, столкнувшись с Lazy load.
2) Далее, возникает вопрос - ну а как мне получить теперь список сотрудников департамента? Очень легко - надо просто написать fine-grained сервисы, которые будут это делать.
То есть вместо:
1.
2.
3.
public interface DepartmentService {
public Department getById(Long id); // выдали Deaprtment с опасным неинициализированным полем employees
}
Сделать
1.
2.
3.
4.
5.
6.
public interface DepartmentService {
public DepartmentDTO getById(Long id);
}
public interface EmployeeService {
public List<EmployeeDTO> getByDepartmentId(Long id);
}
3) Ок, интерфейсы спроектировали, теперь пишете их реализацию. В реализации надо решить вопрос, как мапить данные из сущностей на данные DTO. Можно руками перегонять, можно воспользоваться какой-нибудь библиотекой, типа commons beanutils.
4) Сервисы готовы, DTO готовы, вводим сессию сервелетов.
5) Далее, надо спроектировать контекст пользователя, в котором будут храниться данные обо всех внесенных им изменениях. За основу можете посмотреть на иходники класса ActionQueue в Хибере. То есть это будет что-то типа (пишу, что сходу в голову пришло):
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
// Общий контекст
public class UserContext {
private Map<Class, ActionListBean> context;
// какие-то методы на ваше усмотрение
}
// Тут храняться все изменения, внесенные пользователем в рамках конкретного класса
public class ActionListBean<ID, T> {
private Map<ID, T> createActions;
private Map<ID, T> saveActions;
private List<ID> deleteActions;
}
6) Далее пишите контроллеры. Что они будут делать? Два действия - сначала лезут в соответствующий сервис, получают инофрмацию из БД, потом проверяют контекст на наличие изменений, применяют их, потому выдают моедль пользователю.
Пример - получения списка сотрудников департамента:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
public List<Employees> getEmployeesByDeptId(Long deptId, Session session) {
UserContext userContext = (UserContext)session.get(USER_CONTEXT);
EmployeeService employeeService = // получили или заинжектили сервис
List<Employees> employees = employeeService.getByDepartmentId(deptId);
ActionListBean<Long, Employee> employeeActionList = userContext.get(Employee.class);
List<Employees> actualEmployees = new ArrayList<Employees>();
for (Employee employee : employees) {
if (!employeeActionList.getDeleteActions().contains(employee.getId())) {
if (employeeActionList.getSaveActions().contains(employee.getId())) {
// применили изменения
}
}
actualEmployees.add(employee);
}
// а тут добавили к списку actualEmployees все, что есть в employeeActionList.getCreateActions()
return actualEmployees;
}
7) Ну и, наконец, создаете контроллер, который будет сохранять в БД все, что есть в UserContext, когда пользователь желает сохранить изменения.
Все. Громоздко? Да. Но зато это правильный подход, который использует все сильные стороны ООП и вообще никак не зависит от всяких Lazy-загрузок и сессий хибера. Вам не надо детачить сессию и потом заново приаттачивать, вам не надо беспокоиться о длинных транзакциях - их тут просто нет, вам не надо беспокоиться о том, когда Хибер вздумает зафлашить что-то, и т.д..
Для тех, кто читает невнимательно или желает потроллить, повторюсь - это псевдокод, он не предназначен для использования. Его цель - только показать идею.
Второй важный момент. То, что я написал, это пример того, как делается "по уму". Но, к сожалению, коммерческое программирование это не академическая наука, а бизнес. И бизнес обязывает подстраиваться под него - под бюджет, под временные рамки, под политическую подковерную игру, под заморочки и тараканы определнных людей, и т.д.. Невозможно все всегда делать по уму - бизнес тупо не ползволяет. А поэтому надо всегда сначала формировать в голове правильное решение, а потом думать, несколько окружающая обстановка позволяет его применить. Если позволяет - отлично, применяем. Если не позволяет (сроки горят, менеджер задуплил по жесткому и т.д..), то надо подстраиваться под ситуацию, и, возможно, отказываться от правильного решения в пользу того, которое наиболее подойдет к конкретной ситуации.
Я кончил, сотрите с доски
