私はJPAに慣れていませんが、このシナリオがあります:KISS/DRYの理由で、サーバーとクライアント(Java SE)の両方で同じクラス(「コード」を読む)を使用したいと考えています。これを行う可能性のある方法の1つは、エンティティへのリクエストをサーバーに渡し、最後にすべてのエンティティをサーバーに戻して「バッチ・パーシスト・アクション」を送信する(特殊な)EntityManager
をクライアント上に持つことです。クラスがデータの検証(再検証)、トランザクション操作(更新と処理)を適用し、すべてJPA実装によってうまく維持される場所。リモート管理されたエンティティを持つことは可能ですか?
質問は:それは可能ですか?どうやって? (?このためのソリューションがすでにあり、それは「一部」のコードでこれを解決するために、一種の、シンプルなのですか?)
編集: [OK]を、私はみんなのために物事のカップルを明確にしましょう。私の背景は、ジェネリック・パーシスタンス・サービスと呼ばれることがあるものを使用する社内で成長したアプリケーション・フレームワークです。単一のトランザクション内でCRUDアクション(テーブル内のアクションごとに1つのサービス)を実行するサービスですが、これらのアクションをインターセプトし、検証と(しばしば)複雑なビジネスルール(他のテーブル、等。)。これは古いMicrosoft製品で実装されました。 DevForceやCSLAのような、以前は類似しているが高度なフレームワークが登場した.NETへの移行があります。 DevForceは、特に私がJavaでやりたいことを提供しています(詳細については、this pageの「クライアントで実行する」の段落を参照してからthis pageを参照してください)。
この一般的なテーマに関する私の古い質問:Java "equivalent" to CSLA
デタッチされたエンティティをクライアントに送信して変更し、再接続と永続性のためにサーバーに戻す方法とはどのように違いますか? –
@edalorzoそれは私が言っていることですが、... "経営"がキーワードです。私のクラスはJPA対応であるため、クライアント上にEntityManagerを持っていて、私が作業していたエンティティをすべて「パックアップ」して送ることができますか? 1つのトランザクション・スワップで永続性を適切に処理できる一部のサーバー上のEntityManager? – Doc
私はまだあなたのシナリオを理解しているとは思わない。私の見解では、クライアントはエンティティマネージャーのようなものが存在することを知るべきではありません。ビジネスインタフェースを介して正しく公開されているため、クライアントから要求されたときに単一のトランザクションスウォープで提案したすべての作業を実行することができ、エンティティはサーバーの安全性を放棄することもありません。同時性に関しては、クライアントごとに永続コンテキストを持つことは悪夢である必要があります。並行性のレベルによっては、すべてのクライアントが非常に短時間で無効なキャッシュになる可能性があります。あなたは思いませんか? –