Как GWT RequestFactory .edit() и отправка дельтах работать и как настроить его

Question

я заметил, что когда я призываю

SomeProxy proxyNew = someRequestContext.edit(proxyOld); 
    proxyNew.setSomething(somethingNew); 
    someRequestContext.mySaveMethod(proxyNew).fire(); 

Субъект вернулся из

@Override //from Locator<SomeEntity ,IdClass> 
    public SomeEntity find(Class<? extends SomeProxy > clazz, IdClass id) { 
    ... 
    } 

используется сервер при сохранении метод, и только значения свойства/istance переменной proxyNew переносятся на реализацию сервера mySaveMethod(SomeEntity entity), которые являются новыми по сравнению с возвращенным объектом.

Теперь. Я понимаю, что есть некоторое сравнение, чтобы обеспечить серверную сторону только дельтами, поэтому эффективность в общении, но я думаю, что она каким-то образом компенсируется дополнительным временем обработки/передачи, необходимым для реализации public SomeEntity find(Class<? extends SomeProxy > clazz, IdClass id), которая извлекает объекты сущности из базы данных.

Вопрос теперь в том, как это должно быть правильно реализовано в системе с службами persistence, предоставляемыми через сеансовый bean-компонент без состояния, которые предоставляют услуги серверам GWT-серверу/объектам DAO. Правильно реализовано таким образом, чтобы достичь максимальной эффективности и наименьшего времени ожидания. Также может ли кто-нибудь объяснить мне этот аспект/процесс RequestFactory более подробно?

Мой пример: Я извлекаю объекты OrganizerEntry из слоя сохранения на определенный промежуток времени - неделю.

Таким образом, метод, подобный retrieveOrganizerEntries(Date from, Date to), вызывается в настойчивом слое.

Затем я вижу, что для каждого объекта-объекта OrganizerEntry, который должен быть отправлен на клиентский уровень, выполняется другой запрос, например retrieveOrganizerEntry(int id).

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

Как это можно улучшить? Должен ли я кэшировать объекты DAO/servlet как-то результаты первого запроса и позволить public SomeEntity find(Class<? extends SomeProxy > clazz, IdClass id) искать кеш? Является ли способ реализовать этот метод, возвращая null или вновь созданный пустой объект (new OrganizerEntity()) и перед вызовом метода persist/save от клиента, просто устанавливающего каждое значение переменной свойства/экземпляра?

Где я могу найти дополнительные примеры и объяснения по этому поводу? Потому что http://www.gwtproject.org/doc/latest/DevGuideRequestFactory.html кажется мне не очень утомительным.

Answer 1

1.) Что касается внутренних элементов rf, вы можете обратиться к этому document. Но я думаю, что Томас Бройер собирается ответить на это более подробно.

Основной поток имеет следующий вид:

• свойства, которые представляют собой модифицированное через инкубатор передается на сервер.
• сервер использует find() для извлечения объекта и вызывает соответствующий setters (независимо от того, что вы также вызывали на клиенте).
• Правила валидации обработаны
• Сущность передается вашему методу обслуживания.

2.) С RF вам нужно one session per http request ака OpenSessioninview pattern. , Кэш первого уровня вашего уровня персистентности (то есть Hibernate) должен сделать многократные избыточные вызовы для find() действительно эффективными, поэтому вы обычно попадаете в базу данных только один раз во время жизни сеанса.

3.) Если вы не заботитесь о EntityProxyChange события на клиенте можно переопределить метод isLive() вашего Locator и просто вернуть true (см here для более подробной информации). Вероятно, это также причина, по которой метод find() вызывается, когда вы извлекаете список из OrganizerEntry экземпляров, потому что для каждого OrganizerEntryRF проверяет, жив ли он еще, вызвав 'isLive()', который сам вызывает find().