Сохранение моделей в сеансе - PullRequest
1 голос
/ 09 декабря 2011

Я использую подход Martijn для EntityModel: http://wicketinaction.com/2008/09/building-a-smart-entitymodel/

Я использую EntityModel для хранения данных в своей пользовательской сессии калитки.

 private IModel<Order> order;
 private IModel<User> user;

Это установлено так:

getSession().setOrder(new EntityModel<Order>(order));

Мое приложение представляет собой транзакцию заказа в виде мастера с приблизительно 7, 8 связанными страницами.На некоторых страницах сохраняется множество объектов, но не все.Таким образом, использование EntityModel позволяет мне хранить только непереданные объекты в сеансе, в то время как сохраненные объекты просто хранят уникальный идентификатор.

Проблема в том, что метод detach() никогда не вызывается, потому что модель нене в каком-либо компоненте.

  • Является ли сохранение моделей в сеанс правильным подходом?
  • Нужно ли вручную detach() вызывать в сеансе для каждой модели?

Ответы [ 2 ]

4 голосов
/ 09 декабря 2011

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

Если вы храните вещи в своем пользовательском расширении WebSession Wicket, вы можете переопределить detach() метод класса Session Wicket в вашем добавочном номере:

@Override
protected void detach() {

    // detach the models you're holding in your custom session 
    // by calling all their detach methods.

    super.detach();
}
1 голос
/ 09 декабря 2011

Нет, хранение моделей в сессии не очень хорошая идея. Сеанс Wicket используется разными запросами с разными жизненными циклами и, следовательно, разными потоками. Разделение объектов таким способом вызовет все виды тонких проблем.

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

В качестве альтернативы, вы можете хранить данные как метаданные RequestCycle. Если хотите, вы можете использовать мой RequestCycleCache .

public User getUser() {
  return RequestCycleCache.getOrCreate(USER_KEY, _userId, FETCH_USER_FUNCTION);
}
...