Как предотвратить избыточные постоянные вызовы из контекста GWT RequestFactory? - PullRequest
Новая
       34

Как предотвратить избыточные постоянные вызовы из контекста GWT RequestFactory?

3 голосов
/ 06 октября 2011

В моем проекте у меня GWT EntityProxy упрощен следующим образом: 

@ProxyFor(value = Item.class, locator = ItemService.class)
public interface ItemProxy extends EntityProxy
{
    String getName();

    // other getters and setters here
}

с соответствующей реализацией сущности, которая является простым аннотированным бином сущности JPA.

Я такжеимеет контекст запроса: 

@Service(value = ItemService.class, locator = InjectingServiceLocator.class)
public interface ItemRequestContext extends RequestContext
{
    Request<List<ItemProxy>> findItems();
}

и соответствующие реализации службы и локатора: 

public class ItemService extends Locator<Item, Long>
{
    @Override
    public Item find(Class<? extends Item> clazz, Long id)
    {
        return getItemFromJpa(id);
    }

    public List<Item> findItems()
    {
        return getAllItemsFromJpa();
    }

    // Remaining Locator and JPA methods skipped
}

Когда я вызываю метод findItems в контексте запроса GWT с точки зрения RPC, все кажетсяработать должным образом, и я получаю список элементов в методе обратного вызова для работы с клиентом.

Но с точки зрения персистентности реализация не работает должным образом: на стороне сервера метод findItemsВызванный, как и ожидалось, забирает мои вещи из персистентности и возвращает их.Затем для каждого отдельного элемента метод find вызывается с идентификатором элемента и, конечно, извлекает элементы снова из персистентности один за другим.

Что заставляет контекст фабрики запросов GWT выполнять эти бесполезные вызовы и как можноЯ мешаю это делать?

1 Ответ

4 голосов
/ 06 октября 2011

Перед возвратом в браузер RequestFactory проверит каждый объект домена, который он видел (либо в запросе, либо в возвращаемом значении методов службы), чтобы выяснить, существует ли он по-прежнему или нет, и таким образом определит, должен ли он сообщитьклиент, что объект был удален (генерирует событие EntityProxyChange с WriteOperation.DELETE).

Эта проверка выполняется путем вызова метода локатора isLive, реализация которого по умолчанию вызывает find с объектомИдентификатор и проверяет, является ли возвращаемое значение null.

Другими словами, вы можете просто переопределить isLive в вашем локаторе, чтобы обеспечить свою собственную логику и, возможно, пропустить вызов на уровне постоянства.

...