3

私のプロジェクトでは、GWTEntityProxyを次のように簡略化しています。

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

    // other getters and setters here
}

単純なJPA注釈付きエンティティBeanである対応するエンティティ実装を使用します。

リクエストコンテキストもあります：

@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
}

RPCの観点からGWTリクエストコンテキストでメソッドを呼び出すと、findItemsすべてが期待どおりに機能しているように見え、クライアントで機能するコールバックメソッドのアイテムリストを取得します。

ただし、永続性の観点からは、実装は期待どおりに機能しません。サーバー側では、メソッドfindItemsが期待どおりに呼び出され、永続性からアイテムをフェッチして返します。次に、アイテムごとfindに、アイテムのIDを使用してメソッドが呼び出され、もちろん、永続性からアイテムを次々に取得します。

GWTリクエストファクトリコンテキストがこれらの役に立たない呼び出しを行う原因と、それを防ぐにはどうすればよいですか？

4

1 に答える 1

4

ブラウザに戻る前に、RequestFactoryは（リクエストから、またはサービスメソッドの戻り値で）表示したすべてのドメインオブジェクトをチェックして、それがまだ存在するかどうかを確認し、クライアントに次のことを通知する必要があるかどうかを判断します。オブジェクトが削除されました（でEntityProxyChangeイベントを生成しますWriteOperation.DELETE）。

このチェックは、ロケーターのisLiveメソッドを呼び出すことによって行われます。このメソッドのデフォルトの実装はfind、オブジェクトのIDを使用して呼び出し、戻り値がであるかどうかをチェックしますnull。

isLiveつまり、ロケーターをオーバーライドして独自のロジックを提供し、永続層への呼び出しをバイパスすることができます。

于 2011-10-06T11:06:04.117 に答える