問題タブ [onion-architecture]

CodeCampServer ソース コードには、汎用のStaticFactoryが含まれています。

これは、フレームワークが Dependency Injection でうまく機能するメカニズムの重要な部分であると推測しています。

そのサブクラスは、DefaultUnconfiguredState を使用して静的アクセスを提供します。つまり、依存関係解決メカニズムが動作するものに置き換えることができる Default Unconfigured State への静的アクセスを提供します。

これに関するドキュメントを見つけることができませんでした...

本に良い説明はありますか？(Amazonからの発送待ちです…)

...または、これが何であるか、およびこのパターンを採用するのが賢明かどうかについて、他の誰かが良い解説を提供できますか?

アップデート

Jeffrey Palermo がこの質問に答えたので、MVC2 in Action の (進行中の) 原稿で、このパターン/スタイルが説明され、ドメイン層を無視するためにリポジトリを見つけるために使用されるファクトリを使用して示されていることがわかります。持続性の懸念。(第 23 章を参照)。

デフォルトでは、このファクトリを使用すると例外がスローされます。

「リポジトリを作成する方法の知識は、ファクトリにはありません。このファクトリは、リポジトリを返す機能を表すだけです」

この例では、リポジトリ インターフェイスの具体的な実装を初期化するためのいくつかのメカニズムの 1 つを使用できます。本の例では、簡単にするために IOC コンテナーを使用しないことを選択し、一部の起動ロジックで明示的に提供しています。

「重要なことは、Core プロジェクトも UI プロジェクトも、本質的に純粋にインフラストラクチャであるインフラストラクチャ プロジェクトまたはライブラリを参照してはならないということです。アプリケーションの残りの部分がどのようにデータアクセスが発生しています」

この新しい章のサンプル コードに関する最後の注意点は、Factory が静的ではなくなったことです (少なくとも、外部に面したインターフェイスに関する限り)。

更新 2

Palermo 氏は、Abstract Factory のこの特定のスタイルについてさらにブログを書いています(OrderShipperFactory の実装を参照してください)。

「手動依存性注入」 (ボブおじさん)も検討できます。

更新 3 - 2016 年 3 月

ここに別の例がありますが、Jeffrey はこれがデモ コードであることを明示しており、コメントは、これが Mark Seeman がコンポジション ルートと呼ぶもの(つまり、アプリケーションの起動時)で構成されることを示しています。

これは、Jeffrey の記事「Onion Architecture: Part 4 - After Four Years」で発見しました。

JeffreyPalermoによって記述されたOnionArchitectureを使用してASP.NETMVCアプリケーションを設計しています。

これはASP.NETMVC2.0プロジェクトであり、専用のビューモデルを使用してすべてのビューを厳密に入力する必要があります。ドメインモデルをビューに渡すことはありません。AutoMapperを使用して翻訳を行っています。AutoMapperはインフラストラクチャで分離されており、WebはAutoMapperが使用されていることを認識または認識していません。

現在、WebプロジェクトでIViewModelMappingインターフェイスを定義しています。これは、このサービスがコントローラーによって使用され、独自のビューモデルに直接アクセスできるためです。このようにして、インターフェイスはドメインモデル（コアの場合）とビューモデル（Webの場合）の両方にアクセスできます。

IViewModelMappingインターフェイスの実際の実装を提供するために、インフラストラクチャプロジェクトにObjectMapping名前空間を作成しました。これにより、実際のマッピング実装がタマネギの内部構造に分離されます。その際、インフラストラクチャはコアとWebの両方に依存する必要があります。

私の質問は、これらのプロジェクトは両方とも技術的にはタマネギの郊外（同じレイヤー内）にあるため、1つのプロジェクトがそのレイヤー内の別のプロジェクトに依存することを許可されていますか？このデザインの潜在的な落とし穴に気付いた人はいますか？

別の設計では、IViewMapperインターフェイスをCoreに移動しますが、CoreにはViewModelクラスへのアクセス権がないため、これは不可能です。ビューモデルをコアに移動することもできますが、UIレイヤーに固有であるため、コアには属さないように感じます。

提案されているアーキテクチャは次のとおりです。インフラストラクチャはコアとWebに依存していることに注意してください。Webは分離されたままであり、コアビジネスロジックにのみアクセスできます。

http://www.matthidinger.com/images/onion-arch.png

ドメイン駆動設計（DDD）とジェフリーパレルモの「オニオンアーキテクチャ」との関係は何ですか？

これが私の質問です。それから私はあなたにそれらの背景を与えます：

• アプリケーションの設計として方法2を使用したいので、ビジネス以外のコードへの参照を導入したり、コアプロジェクトのデータベースモデルへのアクセスを許可したりせずに、方法1のようなフィルタリングを提供する方法はありますか？

• コードの再利用をどのように処理しますか？各オブジェクトの名前空間はProject.Core.DomainやProject.Core.Servicesのようなものですが、奇妙に感じる場合は、そのプロジェクトに保存されていないときに名前空間をCompanyName.Core.Domainのようなものにします。現在、これを処理するためにソースコードファイルをコピーし、名前空間の名前を変更していますが、これを処理するための組織的な方法や、私が考えていなかった何かがあるかどうか疑問に思っています。

私が使用しているテクノロジー：

• ASP.NET MVC 3
• Linq-to-SQL
• StructureMap
• Moq
• MSTest

方法1：

Webプロジェクトのセットアップに使用した方法は次のとおりです。

データプロジェクトには、すべてのリポジトリとLinqデータコンテキストが含まれます。リポジトリでは、IQueryableを使用してデータベースからオブジェクトのコレクションを返します。

これにより、静的メソッドであるフィルターをセットアップすることができました。これらもデータプロジェクトに保存されました。

サービスレイヤーでは、このようにフィルターを適用できます。

したがって、リポジトリは、すべてのアイテムをIQueryableオブジェクトとして返すListAllメソッドを提供するだけでよく、サービスレイヤーは、データのサブセットを返す前に、それをフィルターで除外する方法を決定します。

私はこのアプローチが好きで、サービスにコードの大部分を残しながら、リポジトリをよりクリーンにしました。

方法2

現在、Webプロジェクトを設定する方法は次のとおりです。

オニオンアーキテクチャの使用：

• コア：ビジネスドメインモデル、アプリケーションのすべてのインターフェイス、およびサービスクラスの実装が含まれています。
• インフラストラクチャ：リポジトリの実装、Linqデータコンテキスト、およびLinqデータベースモデルをビジネスモデルにマップするためのマッピングクラスが含まれています。

ビジネスコードをデータベースコードから分離しているので、IQueryableにアクセスするために、コアプロジェクトでLinqなどに参照を追加したくありません。そのため、リポジトリレイヤーでフィルタリングを実行し、データベースモデルをドメインモデルにマップしてから、ドメインオブジェクトのコレクションをサービスレイヤーに返す必要がありました。これにより、リポジトリにメソッドが追加される可能性があります。

私は、パレルモ（http://jeffreypalermo.com/blog/the-onion-architecture-part-3/）によって提案されたオニオンアーキテクチャを試行する次の内部アプリケーションのプロジェクト構造を設定しています。

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

図の前に、質問：

1. 参照はすべて正しいと思います（矢印が「への参照がある」を意味する図のように設定されています）が、ある程度の検証は良いでしょう。

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

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

4. 何をどこに行けばいいの？[私が知っている幅広い質問...]

簡略化された概念図は次のとおりです（フォルダーは名前空間を表します）。

新しい「エンタープライズソリューション」を構築する予定です

そこで、柔軟なアーキテクチャを使いたいので、 「オニオンアーキテクチャ」を使用することにしました。

しかし、私は「依存関係の解決」の懸念に不慣れです。

私が理解しているように、ファクトリの「実装」をこのレイヤーに配置する必要があります。このレイヤーには、他のすべてのレイヤーへの参照があります。

次に、DependencyResolutionレイヤーとUIレイヤーのFactoryImplementationに「DependencyResolutionレイヤー」への参照がない場合に、「UIレイヤー」にIFactoryの新しいインスタンスを作成する方法を知りたいです。

編集：：

エリックさんに感謝します

しかし、これらのリンクの多くを見た後、UIプロジェクトでこのようなことを行うことができないため、実装を「インターフェイス」に「登録」したいときにまだ問題があります。

TaxCalculatorUIプロジェクトは「実装」にアクセスできないためです。

私は Onion アーキテクチャについて調べてきましたが、DI コンテナーがすべてを接続できるようにするには、アセンブリの依存関係をどのように配置する必要があるかについての簡単な質問だと思います。

次の構造を持つ非常に単純なソリューションを想定します。

UI => BL <= DAL

したがって、UI と DAL は BL を参照しますが、お互いを認識していません。

また、BL には IDatabaseService というインターフェイスがあり、DALDatabaseService によって DAL に実装されているとします。

コンテナーは (おそらく) UI のエントリ ポイントで構成されます。UI は DAL を認識していないため、IDatabaseService を登録して DALDatabaseService に解決するにはどうすればよいでしょうか?

私はタマネギの建築を数日間研究しています。依存性は常に中心に向かうべきであり、これを達成するために依存性注入を使用する方法を理解しています。しかし、まだ理解できない質問がいくつかあります。

1. モデル（またはエンティティ）はリポジトリインターフェイスまたはサービスインターフェイスを参照できますか？

   例：Orderエンティティには、外部キーではありませんが一意であるプロパティDeliveryCityを通じて確立された関係があります。市をzipで取得するには、電話する必要がありますOder.DeliveryZipICityRepository.FindByZip(zip)

   モデルに次のコードがあります

   /li>

2. 上記のコードの問題は何でしょうか？代わりにドメインサービスを使用する必要がありますか？

3. ドメインサービスの実装は、コア内で定義する必要がありますか、それともインフラストラクチャ層で定義する必要がありますか？

J. Palermo によるオニオン アーキテクチャを適用しようとしていますが、苦労していることがいくつかあります。

パーツがいくつかあり、どこに配置すればよいかわかりません。

• ディレクトリを読み取り、何をロードするかを決定するプラグイン エンジンがあります。
• いくつかのプロジェクトで使用される翻訳を含むいくつかのリソース ファイルを用意します。これらのファイルはどこに置くべきですか?
• システム全体で使用されるいくつかの属性があります。これらをどこに置く？
• また、2 つの「ベース」コントローラ、いくつかのデフォルトの結果とビューがあります。これらはどこに置けばいいですか？

これらのアイテムはすべて複数のプロジェクトで使用されているため、アイテムを中心に配置したいと考えています。

私の現在のソリューション構造は次のようになります。

• Project.Core (リポジトリのドメイン オブジェクトとインターフェースを含む)
• Project.Infrastructure (コアの実装です)

MVC2を使用しています。

流暢な構成からいくつかのあいまいなエラーが飛び出すという問題があります。ログ ソリューションを設定すると、問題を解決するのに役立つと読みました。NLogを使用したいと思います。Common.Logging 2.0 と NHibernate.IInterfaceLogger を使用して実行する必要があることを理解しています。ピースをどのように組み立てるかわかりません。私のシステムは、Onion Architecture に基づいています。NLog 用にログ サービスをセットアップし、そのためのインターフェイスを用意しましたが、これらすべてをどこにバインドすればよいか少し混乱しています。私の Fluent NHibernate 構成は、私のデータ プロジェクトに存在します。私は、これらすべてをそこで結び付けたいと思っていると思います。

これについての考えは素晴らしいでしょう！私は少し迷っています！