1

さまざまなSpringデータリポジトリ（gemfire、jpa、mongodbなど）を使用していくつかのエンティティクラスを永続化する必要があるプロジェクトをまとめようとしています。これらのリポジトリに入れる必要があるデータは多かれ少なかれ同じであるため、あるオブジェクトから別のオブジェクトに変換する手間を省くために、それらすべてに同じエンティティ クラスを使用できるかどうか疑問に思っていました。

gemfire と jpa で動作するようになりましたが、エンティティ クラスはすでに少し配線されているように見え始めています。

@Id // spring-data-gemfire
@javax.persistence.Id // jpa
@GeneratedValue
private Long id;

これまでのところ、次のオプションが表示されます。

  1. インターフェイス ベースの個別のエンティティ (ドメイン) クラスを作成する - 同じクラスを再利用しようとすると、時期尚早の最適化のように見えます。
  2. JPA の xml ベースのマッピングを外部化します。gemfire と mongodb のマッピングを外部化できるかどうかは不明です。
  3. さまざまな具象エンティティ クラスを使用し、変換のためにいくつかのコピー コンストラクター/コンバーターを使用します。

最善のアプローチを見つけるために文字通り壁に頭をぶつけてきました - どんな反応でも大歓迎です。ありがとう

4

1 に答える 1

1

奇妙なことに、アプリケーションドメインオブジェクト/エンティティクラスが、エンティティが配置されるさまざまなデータストアに対して、多くの異なるが個別の (マッピング) 注釈 (SD Commono.s.data.annotation.Idや JPA など、意味的に同じものもあります) を蓄積し始めていることを意味します。@javax.persistence.Id持続しているなら、それは理解できると思います。

エンティティの表現の数が増えるにつれて、注釈汚染も増加するだけです。たとえば、JSON マッピング用の Jackson アノテーションや XML 用の JAXB などを考えてみてください。すぐに、実際のデータよりもメタデータの方が多くなります:-)

ただし、実際には、好み、利便性、シンプルさの問題です。

一部の開発者は純粋主義者で、すべてを外部化することを好みます。また、情報 (メタデータ) をそれを使用するコードの近くに保持することを好む人もいます。これらのタイプの問題に対処するために、特定のパターンも出現しています... DTO、境界付きコンテキスト ( DDD およびマイクロサービスと強い相関関係があるFowler の BoundedContextを参照)。

個人的には、特に新しいものを導入するときに、コードでアーキテクチャのプリンシパル/決定を設計および適用するときに、次のルールを使用します。

  1. シンプルさ
  2. 一貫性
  3. ドライ
  4. テスト
  5. リファクタリング

(他にもいくつかあります... 優れた OOD、SoC、SOLID、デザイン パターンなど)。

それもその順番で。何かが複雑になり始めたら、リファクタリングして単純化します。パターンや慣習に従う/使用することで、一貫性を保ちます。親しみやすさは、一貫性の 1 つの鍵です。しかし、自分自身を繰り返し続けないでください。

結局のところ、それは実際にはアプリケーションを維持することです。あなたが中断したところから再開する他の誰かが、組織とロジックをすばやく理解し、それを維持できるでしょうか... シンプルさが王様です。単純すぎて実行不可能で価値がないという意味ではありません。複雑なものも、きちんと整理すれば簡単にできます。ただし、物事をバラバラにして抽象化を導入すると、隠れたコストが発生する可能性があります (結びの考えを参照)。

あなたの質問（のいくつか）にもっと具体的に答えるには...

  1. MongoDB についてはよくわかりませんが、(Spring Data) GemFire には外部マッピングがありません。エンティティクラスに複数のコンストラクタがある場合に加えて、少なくとも@Region(エンティティ クラスで) と@Idが必要です。@PersistenceConstructorたとえば。_

  2. これは、こっそりと DTO のように聞こえます。個人的には、BoundContext は、アプリケーションのデータのより優れた、より自然なモデルだと思います。なぜなら、ドメイン モデルは永続的なストアや外部表現 (JSON、XML など) に過度に結び付けられるべきではないからです。アプリケーション ドメイン モデルは、アプリケーションの 1 つの真の状態であり、何らかの表現や永続的なストア (したがって、マッピング/変換) を満たすために表面的にではなく、自然な方法で表現される概念をモデル化する必要があります。

とにかく自分を責めすぎないようにしましょう。複雑さを管理することがすべてです。テストやその他のフィードバック ループを使用して、自分のアプリケーションに適した答えを見つけるようにしてください。あなたは知っているでしょう。

お役に立てれば。

于 2016-05-25T07:10:02.583 に答える