2

ジェフリー・パレルモはタマネギのアーキテクチャを開拓しました。これは私が良いアプローチを見つけたものです。

http://www.headspring.com/jeffrey/onion-architecture-part-4-after-four-years/

ただし、私の理解が正しければ、「内側のレイヤーはインターフェイスを定義します。外側のレイヤーはインターフェイスを実装します」という彼のステートメントは、コンシューマーがインターフェイスを定義し、プロバイダーがそれを実装する、つまり、コントロールはプロバイダーではなくコンシューマーにあると述べている場合、IoCと矛盾するようです。

この原則は私には理にかなっています。UIを作成していると想像してください。この原則は、すべてを公開するインターフェイスの定義を担当しているため、呼び出すサービスについて何も知らなくてもUIの作成に取り掛かることができることを意味します。必要な機能。

したがって、そのために、Jeffreysのステートメントは矛盾しているように見え、コントラクト（インターフェイス定義）を配置する場所について私を混乱させます。これは、次のことを意味しているように思われるためです。

ドメインの下にレイヤーがないので、IMyEntityをどこに配置しますか。また、ドメインが存在し、IMyServiceを定義するまで、プレゼンテーションプロジェクトを作成できないことを意味します。

ちなみに、IMyEntityRepositoryとMyEntityRepositoryはどこに配置しますか？サービスはIMyEntityRepositoryに依存し、MyEntityRepositoryはIMyEntityに依存するため

4

4 に答える 4

5

では、どこから始めますか？:-)

IOCの本当の役割から始めましょう。ウィキペディアによると、

Inversion Of Control は、オブジェクト結合が実行時にアセンブラー オブジェクトによってバインドされ、通常はコンパイル時には認識されないプログラミング手法です。

あなたの場合、UI は、実行時にバインドされるサービスの実装を知らなくても、サービス インターフェイスを操作します。これらのサービス インターフェイスを定義するのは消費者次第ではありません。これらは Onion アーキテクチャのアプリケーション コアで定義されますが、後で説明します。

「内層はインターフェースを定義し、外層はインターフェースを実装します」、それがオニオン アーキテクチャの設計方法ですが、最外層が IOC であることを忘れないでください。実行時にインターフェイスを適切な実装にバインドするのは、IOC 次第です。

操作するインターフェイスに少なくとも 1 つの実装が利用可能でなければ、UI は機能しないと言っているのは正しいことです。ただし、この場合、なんらかの理由で最初に UI を作成する必要がある場合は、モック フレームワークの使用を検討してください。

最後の質問は、IMyEntityRepository および MyEntityRepository クラスをどこに配置する必要があるかについてです。まあ、それは簡単な部分です ;-) IMyEntityRepository は間違いなくアプリケーション コア内に配置する必要があります。すべてのエンティティ、サービス インターフェース、リポジトリ インターフェース、およびあらゆるインターフェースが同じ場所にある必要があります。MyEntityRepository の実装は、インフラストラクチャ層のどこかに配置する必要があります。彼の役割は主に DB からデータを取得することです。

それが役立つことを願っています!

于 2013-03-01T15:24:14.763 に答える
4

私は長年ジェフリーと仕事をしてきましたが、IoC は Onion Architecture を可能にするために不可欠であると言えます。外部依存関係のインターフェイスは、依存関係がほとんどない (存在する場合) プロジェクト (つまり、タマネギの「中心」にあるプロジェクト) で定義されます。外部の依存関係に依存するインターフェイスを実装するクラスは、タマネギの端/表面のプロジェクトにあります。次に、IoC コンテナーは、実行時にオニオンのエッジにあるクラス実装をオニオンのコアにあるインターフェイスに「接続」するために必要です。

于 2013-03-01T16:17:01.057 に答える
2

私のプロジェクトに Onion を実装しましたが、概念的には非常にシンプルです。

  1. インターフェイスと POCO のみを含むプロジェクトを作成します。ここでは、これを Contract と呼びます。
  2. インターフェイスの実装と、NHibernate マッピングなどのすべてのサードパーティのものを含む 1 つ以上のプロジェクトを作成します。これを実装と呼びます。
  3. この機能を使用する必要があるプロジェクトから契約への直接参照を追加しますが、これらのプロジェクトから実装への参照を追加しないでください
  4. 複合ルート (アプリケーション エントリ ポイント) で、プロジェクトは 2 つのことを行います (1) ビルドの一部として、最新バージョンの実装を構成済みの場所にコピーします (構成には AppSettings を使用しますが、ここには多くのオプションがあります) (2)コンテナに実装DLLの構成された場所をスキャンさせます

このアプローチでは、Contract のみに依存することができ、実装を切り替えることができるため、将来 Entity Framework などに移行する場合は、そのフレームワークを使用して実装を再実装するだけで済みます。

また、NHibernate DLL を構成されたスキャン場所にコピーします。これにより、NHibernate は使用する必要がある場所でしか使用できないため、アーキテクチャを守らないようにすることができます。

于 2013-03-01T19:01:06.387 に答える
0

オニオン アーキテクチャのインターフェイスは、層が依存する(つまり、消費する) ものであり、その実装は実際には外側の層によって提供されます。

より具体的には、アーキテクチャ自体は、インターフェイスの背後にあるビジネス ロジックを抽象化する必要があるとは言っていません (依存性逆転の原則に関しては、おそらくとにかく行う必要がありますが、それは別の話です)。つまり、レイヤーの依存関係をインターフェイスとしてモデル化して、外側のレイヤーによって実装を提供できるようにする必要があります。

最適な例は、インフラストラクチャコード、特にデータ アクセスです。ビジネス ロジックはデータを読み込んで保存する必要があるため、使用するインターフェイスを定義します。外側の層は、NHibernate や EF などを使用した実装を提供します。

実際には、低レベルのレイヤー(DIP、つまりデータ アクセスやその他の商品) はタマネギの最も外側のレイヤーにあり、高レベルのレイヤー(つまり、ビジネス ロジック) は中心に近いです。

ドメイン、ビジネス ロジック、その他のビジネス ロジック用語をエンティティ、ユース ケース、インターフェイス アダプターに置き換えるhttp://blog.8thlight.com/uncle-bob/2012/08/13/the-clean-architecture.htmlも参照してください。どのIMOが推論しやすいか。中心から離れれば離れるほど、ユーザーが見たり使用したりするものに最も具体的になります。中心に近いほど一般的です。中心にあるのは企業に横断的なものであり、アプリに固有のユースケースは、それらがどのように使用されるか、どの環境 (どの DB、どの UI など) で使用されるかを決定するものではありません。ユース ケースとテクニカル フレームワーク (ASP.NET MVC、WCF、WPF (非 Web シナリオ)、EF、NHibernate など) の間にアダプターを作成します。

于 2013-04-27T14:00:49.730 に答える