タマネギのアーキテクチャ

Question

パレルモ（http://jeffreypalermo.com/blog/the-onion-architecture-part-3/）が提案したタマネギのアーキテクチャを試験する、今後の内部アプリケーションのプロジェクト構造を設定しています。

私は彼のガイドラインに従っていますが、これまでのところプロジェクトの構造について何らかの検証が必要です。図の前に

質問：

1. 私は参照はすべて （矢印は「はへの参照を持っている」という意味の図のとおりに設定）が正しいですが、いくつかの検証は良いことだと思います。

2. 依存関係解決レイヤーには何を入れる必要がありますか？これはどこですか？ 助手が行くのですか？これには他のすべてのプロジェクトへの参照がありますか？

3. Webサービスはどのようにして& UI、DALと通信しますか？ （コアを通して？）

4. どうすればよいですか？ [私が知っている幅広い質問...]

次のように単純化された概念図は、（フォルダの名前空間を表す）である：

Answer 1

私は、参照は、すべてが、いくつかの検証が良いでしょう（矢印は「はへの参照を持っている」という意味の図のとおりに設定）が正しいと思います。

1これは正常に見えますが、ダイアグラムに依存性の解決を挿入することをお勧めします。

依存関係解決レイヤーにはどのような設定をする必要がありますか？ヘルパーが行く場所ですか？これには他のすべてのプロジェクトへの参照がありますか？

2私は依存性注入物がここにあると信じています。

ウェブサービスはどのようにして& UI、DALと通信しますか？ （コアを通して？）

3パレルモの図によればコアです。コアでは、リポジトリとドメインモデル、およびリポジトリとドメインモデルを扱うサービス（Webサービスではない）との対話を行います。また、UI/Webサービスは主にサービスと対話します。

どこに行く必要がありますか？ [私が知っている広い質問...]

4答えはパレルモの図であると思います。しかし、私の考えでは、アーキテクチャを完全に理解しているときには、プロジェクトを組織することが異なることがあります。

私はDDDとMVC、依存性注入、リポジトリ/サービス、ORMなどの必要なデザインパターンを理解すると、オニオンアーキテクチャがわかりました。

Answer 2

1. はい彼らは、依存関係のために期待解決。これらの依存関係は、逆になります。
2. 名前（および修正された参考文献）は、 のIoCコンテナソリューションをホストすることを目的としていることを示しています。ヘルパーのための場所ではありません クラスは、解決のためのヘルパークラスを期待しています。
3. コアでは、DALまたはドメインサービスのインターフェイスが定義されています。 DALお​​よび WebServicesはこれらのインターフェイスを実装しています。 UIの内部では、定義されたインターフェイスを通じて DALまたはサービスの実装を使用します。 正しい実装は、 依存関係解決コンポーネント（ "Inversion Of Control"または "Dependency Injection"の概念を見てください）の助けによって解決されます。
4. 3で説明したように、コアでは、DALとWebサービスの内部で実装されるインターフェイスを配置します。コアでは、あなたの実際のビジネスモデルを実装します。このモデルは、（依存関係解決コンポーネントの助けを借りて）定義されたインタフェースを介してDALとWebサービスを利用することができます。