Gwt+Gaeの世界に近づいています。
私の本質的なニーズは、DTO に複製することなく、Gwt-Rpc ワイヤでエンティティ クラスを送信することです。
それをかなりうまくやるという約束を客観化してください。すべての「Jdo の複雑さ」を隠すと主張しています。
私は JPa や Jdo の技術を扱ったことはありません。 すべての複雑さはどこにありますか?
つまり、JDO の複雑なタスクについて、Objectify によって簡単になった簡単な例をいくつか教えていただけますか?
多分関係？
2802 次
2 に答える
9
JDO/JPA は「Hello World」レベルで簡単に操作できると思います。しかし、複合キー、エンティティ間の関係の乗算など、より現実的なものが必要になるとすぐに変更されます。JDO GAE の実装は非常に複雑で、サポートされていない機能、回避策、および拡張機能があるため、初心者にとっては理解しにくいものです。JDO は「どこでも」動作するように設計されています。つまり、高度に抽象化され、非常に一般的な性質を持っています。移植性には優れていますが、非常にユニークなデータストアを持つ GAE のような特定のエンジンには完全に適合しない可能性があることも意味します。Datanucleus/JDO/JPA jar はかなり大きい (合計で ~2.3 mb) のに対し、Objectify の jar はかなり小さいです。JDO/JPA は起動時にクラスパス スキャンを実行してエンティティを検索および登録する場合があり、これにより読み込み時間が長くなる可能性があります。
例にあるように、JDO/JPA サンプルのコード量の点では、Objectify の多くの DAO クラスよりも単純に見えると思いますが、一般に、地雷原を通り抜ける必要がないため、Objectify コードのメンテナンスはエンジニアにとってより簡単になります。 JDOで何を壊すことができるかを考えてください:)
于 2011-11-18T21:16:54.437 に答える
1
JDO の複雑さの一例は、エンティティーが取りうるさまざまな状態の数を確認することです。これが最初は圧倒される可能性がある例として、このページの一番下までスクロールして、その状態図を見てください。Objectify は、そのような状態図を必要としません。
JDO のもう 1 つの厄介な部分は、バックグラウンドで発生するすべての「魔法」であり、デバッグが困難になる場合がありました。もちろん、これは実際には魔法ではなく、バイトコードの書き換えにすぎませんが、それだけでは十分にトリッキーです。
最後に、JDO は汎用 API です。これは、オブジェクト ストア、SQL データベース、および他に何を知っているかで動作するように設計されています。特定の JDO の概念と、データストアで実際に起こっていることとの関連性を理解するのが難しい場合があります。Objectify の API はデータストアと密接に連携しているため、何が起こっているのかを簡単に理解できます。
于 2011-11-19T04:18:53.053 に答える