3

RequestFactory既存の Java エンティティ モデルで使用しようとしています。私たちの Java エンティティはすべてDomainObjectインターフェースを実装し、メソッドを公開しますgetObjectId()(この名前はあいまいで、モデル化されているドメインからのドメイン オブジェクトの実際のIDgetId()と競合する可能性があるため選択されました。

インターフェイスにより、ServiceLayerDecoratorID およびバージョン プロパティのルックアップ戦略をカスタマイズできます。

public class MyServiceLayerDecorator extends ServiceLayerDecorator {
    @Override
    public Object getId(Object object) {
        DomainObject domainObject = (DomainObject) object;
        return domainObject.getObjectId();
    }
}

ここまでは順調ですね。ただし、このソリューションをデプロイしようとすると、ランタイム エラーが発生します。特に、RequestFactoryInterfaceValidator不満：

[ERROR] There is no getId() method in type com.mycompany.server.MyEntity

その後、次のようになります。

[ERROR] Type type com.mycompany.client.MyEntityProxy was previously marked as bad
[ERROR] The type com.mycompany.client.MyEntityProxy did not pass RequestFactory validation
[ERROR] Unexpected error
com.google.web.bindery.requestfactory.server.UnexpectedException: The type com.mycompany.client.MyEntityProxy did not pass RequestFactory validation
    at com.google.web.bindery.requestfactory.server.ServiceLayerDecorator.die(ServiceLayerDecorator.java:212) ~[gwt-servlet.jar:na]

私の質問は、との規則をハードコーディングしているServiceLayerDecorator場合、カスタマイズされた ID とバージョンのルックアップ戦略を許可するのはなぜですか?RequestFactoryInterfaceValidatorgetId()getVersion()

「毒された」プロキシクラスを無視するようにオーバーライドできると思いますServiceLayerDecorator.resolveClass()が、この時点では、フレームワークと戦いすぎているようです...

4

1 に答える 1

3

いくつかのオプションがあり、そのうちのいくつかはすでに言及されています:

  • Locator. 私は、プロジェクト全体、または少なくとも同様のキー タイプを持つ関連オブジェクトのグループに対して 1 つのロケーターを作成するのが好きです。getId() 呼び出しは DomainObject.getObjectId() メソッドを呼び出してその値を返すことができます。このgetDomainType()メソッドは現在使用されておらず、null を返すか、例外をスローする可能性があることに注意してください。
  • ValueProxy. オブジェクトを RF がエンティティとして理解できるものにマップする代わりに、プレーンな値のオブジェクトにマップします。ID やバージョンは必要ありません。RF は、特にサーバーへの冗長データの送信を回避することに関して、できる多くの賢いことを見逃しています。
  • ServiceLayerDecorator. これは 2.4 より前は機能していましたが、現在行われている注釈処理では、作業の一部を実行しようとするため、うまく機能しません。ServiceLayerDecorator はここ数か月で多くの歯を失ったようです - 理論的には、それを使用してゲッターを再構築して永続化メカニズムと直接対話することができますが、注釈処理がコードを検証するため、それはもはやオプションではありません.

これらすべての大きな問題は、RequestFactory が 1 つの問題を解決するように設計されており、それをうまく解決できるようにすることです: 開発者が何らかの永続化メカニズムにマップされた POJO を使用し、クライアントからそれらのオブジェクトを参照できるようにし、特定の規則に従って余分なコードを記述しないようにします。または構成。

その結果、それ自体の問題をかなりうまく解決し、他の多くの問題/ユースケースには適合しなくなります。それだけの価値がないことに気付いているかもしれません。

  • RPC。多くの場合は完璧ではありませんが、多くの場合は問題ありません。
  • AutoBeans (RF のベースになっている) は、データをネットワーク経由で送信してアプリに取り込むための非常に高速で軽量な方法です。RF が行ったように、その周りに独自のラッパーを構築し、解決しようとしている問題をユースケースだけに絞り込むことができます。
于 2011-11-08T16:15:42.470 に答える