web-dev-qa-db-ja.com

Spring Data Repositoryの実装は疎結合の原則に違反していますか？

そのため、現時点では自分のc#/.net（ウェブ）アプリケーション（またはフォルダー/プロジェクト/パッケージ-...）の構造は、次のようになり、「ややオニオンアーキテクチャー的な方法」で考えます。

myApp
    - API
        - Controllers for HTTP, REST etc., may even be a whole gui, though ...
    - Domain.Model
        - "Business Logic" for the actual application, being most 
           of the time a (micro)service...
        - Interfaces for Repositories, Thirdparty(see below)...
    - Infrastructure
        - ThirdParty
            - Call to other Services,
        - Persistence
            - Implementations for Repositories
        - Adapters
            - Adapt some Class to a DTO for my domain 
    - Config
        - global configurations...
    - Tests
        - empty... just kidding.

実際、私はこのセパレーションをたくさん使いたいので、以下について概要を説明します。

  • 現時点で実際に「価値がある」もの（Domain.Model内）
  • 「データを提示する」だけのもの（API）
  • 「周囲の、変化する可能性のある依存関係」とは何ですか（インフラストラクチャ）

だから、私は数週間後に新しい仕事を始めるつもりですJava世界に戻り、春（ブート/クラウド）を多用して新しいアプリケーションを作成します。したがって、業界標準のhibernate-ORMを使用することを検討しますが、JDBIのような軽量のOR-Mapperを使用することも非常に役立ちます。エンティティフレームワークに関しても、同じ動作がわかります。

ここで、Springブートの例を探しました。SpringDataを使用して実際にリポジトリを使用するために、リポジトリの実装を使用する必要がないことを覚えています。

典型的なSpringリポジトリの実装は次のようになります。

Public interface PersonRepository extends CrudRepository<Person, Long> {

  List<Person> findByEmailAddressAndLastname(EmailAddress emailAddress, String lastname);
  ...
}

だから、私は今このインターフェイスをどこに置くべきか自分に尋ねていますか？一見すると、それを自分のDomain.Modelパッケージにリポジトリインターフェースとして入れました。しかし、「バックグラウンドで」飛び出して実際の実装を作成しないで（！）私のdomain.modelを作成し、それを結合します。永続化技術、OR-Mapperなどに？

.NETでは、ドメイン内に単純なI [Class] Repositoryを実際に作成し、Entity FrameworkやDapperなどのインフラストラクチャに実際の実装を追加します。これにより、DBMS全体であっても、ORマッパーを非常に簡単に切り替えることができます。したがって、このようにSpringで実行すると、CrudRepositoryインターフェイスを使用できないため、CRUD操作用のボイラープレートコードが大量に作成されます。

それで、私のdomain.model内に「プレーンな」リポジトリを作成する方が良いでしょうか？しかし、それは私が実際に避けたい大量のボイラープレートコードの始まりではないでしょうか？

たぶん、ここで「フレームワークに逆らって」はいけません。最後の結果として、実際のドメインを100％抽象化するために必然的になりたい場合、Springコンポーネントへの他のすべてのCallに対しても実行する必要があります。技術..？

私はここで少し迷っていますが、それは実際には現時点で私の頭の結び目のようなものです。多分私は明らかな何かを逃している。

Springリポジトリの実装がどのように機能するか、およびDomain.Model内に配置しても問題がない理由を明確にするか、プロジェクトのより良い構造についてアドバイスしながら構造的な誤解を示して、アドバイスをいただければ幸いです。

前もって感謝します！

javadomain-driven-designrepositoryspringproject-structure
3
Dominik

tl; dr

Spring Data Repositoryの実装は疎結合の原則に違反していますか？

いいえ。インターフェースを定義するだけではカップリングはありません。

ロングバージョン

I）プロジェクトレイアウト-およびその意図-関係の分離を達成するために抱いている（APIで階層を大まかに分離しようとしている） 、Domain/ModelおよびInfrastructureと呼びます）。その上、テストと構成があります。

Three-Tier-Architecture は、_presentation tier_、_middle tier_および_data tier_を区切ります。あなたには2つの異なる層があります。つまり、プレゼンテーションと永続性、および「中間にあるもの」を担当します。

したがって、アーキテクチャの観点から見ると、インターフェース宣言は、データ層と通信する中間層の「下端」に属しています。

ドメインオブジェクトにアクセスするためのコレクションのようなインターフェイスを使用して、ドメインとデータマッピングレイヤーの間を仲介します。

from エンタープライズアーキテクチャのパターン

または、次のようにデータ層の「上限」に配置することもできます 図 。とにかく、ドメインオブジェクトからのdistictです。

デザインを改善する最初のステップは、Domain- FolderからInfrastructure-Folderにインターフェイス定義を配置することです。

II）Spring Data works がどのように表示されるかを確認すると、magic@EnableJpaRepositories("com.acme.repositories")を宣言する必要があります。

これにより、DBMS全体であっても、ORマッパーを非常に簡単に切り替えることができます。

エンティティフレームワークと同様に Spring を使用してこれを行うことができます。

次に、それを永続化テクノロジー、OR-Mapperなどに結合しますか？

いいえ。コンテナを構成して「実装」を1つ選択するだけです。しかし、それは結合ではありません。あなた自身のものを提供することは自由です。

0
Thomas Junk