問題タブ [onion-architecture]

私はEntity Framework 6データベースファーストを使用しています。プロジェクトを変換してオニオン アーキテクチャを実装し、関心の分離を改善しています。多くの記事を読み、多くのビデオを見てきましたが、ソリューションの構造を決定する際にいくつか問題がありました。

Core、Infrastructure、Web & Tests の 4 つのプロジェクトがあります。

私が学んだことから、.edmx ファイルは "Infrastructure" フォルダーの下に配置する必要があります。ただし、リポジトリと作業単位のパターンを使用して EF のデカップリングを支援し、依存性注入を使用することについても読んだことがあります。

これが言われていると：

• モデル内のすべてのエンティティに対して、CORE の下にリポジトリ インターフェイスを作成する必要がありますか? もしそうなら、巨大なデータベースでこれをどのように維持しますか? 私は automapper を調べましたが、IEnumerables と IQueryables を提示する問題が見つかりましたが、これを実行する必要がある拡張機能が利用可能です。このルートをさらに深く試すことはできますが、最初に連絡を取りたいです。

• 別の方法として、edmx をインフラストラクチャに残し、エンティティの .tt T4 ファイルを CORE に移動する必要がありますか? これは、密結合または適切な解決策を示していますか?

• あなたが提供する提案で、一般的なリポジトリインターフェースはうまく機能しますか? それとも、EF6 は既にリポジトリと UoW パターンの問題を解決しているでしょうか?

私の質問をご覧いただきありがとうございます。代替の回答も提示してください。

ここで同様の投稿が見つかりましたが、回答はありませんでした: EF6 and Onion architecture - database first and without Repository pattern

Onion Architecture とWindows Forms UI レイヤーを組み合わせているときに問題が発生しました。問題は、IoC 構成メソッドがヒットしないことです。IoC セットアップは、依存関係解決アセンブリで行われます。

そして、UI レイヤーが .NET 以外に依存しないようにしたいと思いProject.Coreます。

このアーキテクチャを使用した Web プロジェクトでは、WebActivatorEx と OutputTo を使用して IoC をブートストラップしました。私はよく知っているので、ここでも同じものを使用することにしましたが、期待どおりに動作しません。私が問題なのか Windows フォームが問題なのかわからないので、私のセットアップは次のとおりです。

Project.DependencyResolution で:

OutputTo の OutputTargets.txt:

Project.UI で:

OutputToDependencyResolution'sは DLL ファイルをUi'sbin に正しくコピーしますが、IocConfig.RegisterDependencies実行されません。

では、Windows フォーム プロジェクトがスタートアップ プロジェクトである独自のアセンブリから IoC をセットアップするにはどうすればよいでしょうか。

オニオン アーキテクチャを順守する ASP.NET MVC 5 ソリューションに Identity 2.0 を実装しようとしています。

私はApplicationUser自分のコアに を持っています。

私のデータ アクセス レイヤーでは、Entity Framework 6.1 を使用しています。私のコンテキストはそこから派生しIdentityDbContext、ここに問題があります。ApplicationUserから派生する必要がありますMicrosoft.AspNet.Identity.EntityFramework.IdentityUser

私のドメイン モデルはMicrosoft.AspNet.Identity.EntityFramework、タマネギの考えに反する参照をすべきではありません。

良い解決策は何ですか？

私のプロジェクトには、リポジトリを操作するサービス レイヤーがあります。サービス層はコントローラーによって呼び出されます。

多くの場合、コントローラー レイヤーは、受信情報がシステムに取り込まれる前に検証できます。ただし、場合によっては、送信されたデータが有効でないためにエラーが発生することがありますが、これはサービス レイヤー内のポイントでのみ発生します。

それを念頭に置いて、ユーザー サインアップ フローを実行していると仮定しましょう。

• 重複したユーザー名は許可されていません
• ユーザー名を指定できます
  • ユーザー名が指定されていない場合は、姓名から生成されます

これは、(必要に応じて) 生成し、重複するユーザー名をチェックするプロセスがサービス層で発生することを意味します。

重複が発生した場合、呼び出し元に信号を送るための最も分離された理想的な方法は何ですか (コントローラー、バックグラウンド タスク、または別のサービスであっても) - それ:

• ユーザー名フィールドに問題があります
• 該当する場合、生成されたユーザー名

理想的には、提案されたアプローチを他のサービスで発生するエラーに適用できるようにして、一貫した方法で報告し、呼び出しレイヤーでエラーを処理できるようにすることができます。

オニオン アーキテクチャのモックアップ

上の 2 つの画像は、Onion Architecture についての私の理解を表しています。それらは、私が答えを見つけることができない議題に対処しているため、オンラインで見つけた図面とは少し異なります。

私が知る限り、インフラストラクチャとは永続性やロギングなどです。それらの例をイタリック体で書きました。ただし、多くの場合、インフラストラクチャ コンポーネントと UI は相互に通信する必要があります。UI は何かを監査またはログに記録したい場合があり、永続化プロジェクトは何かをログに記録する必要がある場合があります。ロギングは、オニオン アーキテクチャに適合させるのが難しい項目の 1 つです。私の理解では、ログを記録する必要がある場所とすべきでない場所について、多くの人が異なる意見を持っています。

最初の図では、図にインフラストラクチャ インターフェイス レイヤーを配置して、1 つのコンポーネントが別のコンポーネントの実装を認識しなくても相互通信できるようにしました。これは、私がいくつかの例で見たものです。

2 番目の図は私の好みです。メディエーターを使用して、インフラストラクチャ、UI、およびコア サービスがインフラストラクチャと間接的に通信できるようにする基本的な方法の間で相互通信します (右側の図ではサービス インターフェイスがコア サービスと呼ばれていると仮定します)。ロガーは、データベースなどと同様に、特定のイベントにサブスクライブします。

最初の図では、外側のレイヤー (依存関係リゾルバーを除く) を除くすべてのレイヤーで poco とインターフェイスのみが許可されます。2 つ目は、コア サービス レイヤーでドメインとビジネス ロジックを許可し、インフラストラクチャ レイヤーが分離してジョブを実行できるようにします。

何らかの出力が得られるようにすることで、インフラストラクチャ コンポーネントを正当化しました。監査とロギングは通常、ある種のデータベースを使用し、キャッシュは通常メモリに保存され、データベースはおそらく永続性と呼ばれるべきでした。ただし、AutoMapper というライブラリがあります。いくつかのインスタンスでラップされているのを見たことがあります。そのため、そのインターフェイスはコアに入ってほとんどすべてのインフラストラクチャで使用できますが、私には抽象化されすぎているように思えます。Automapper は、すべてのインフラストラクチャが自身とドメインの間の変換に使用するという点で Events オブジェクトに似ていますが、サービスではないため、そのレイヤーに適合するかどうかはわかりません。

質問: 2 つのうちどちらがオニオン アーキテクチャの定義に最も近く、自動マッパーのようなツールのどこに当てはまりますか?また、そのようなものをラップしようとすることは抽象化を超えていると思いますか?

ありがとう！

私はベスト プラクティスに従い、主要なビジネス ロジックがサービス レイヤーで実行される場所にコントローラーが傾くようにしています。

以下のアクションでは、Validate Login コードをサービス レイヤーに抽出しましたが、HttpConext.GetOwinContext.Authentication を処理してクレーム ID を作成するロジックをどこに置くべきかわかりません。

このコントローラ アクションにはコードが多すぎるようですが、ここに残しても問題ありませんか? コントローラーにとどまるべきですか、それとも独自のサービス インフラストラクチャまたは何らかの静的クラスに抽出する必要がありますか?

私はこれがどこにあるのか、それが何を保持しているのかについて少し立ち往生しています。

私はオニオンアーキテクチャhttp://jeffreypalermo.com/blog/the-onion-architecture-part-1/に従おうとしています

私はオニオンアーキテクチャを学ぼうとしていますが、私が理解しているように、次のようにソリューションを整理しました:

ドメイン

• Domain.Entities (ビジネス オブジェクト)
• Domain.Interfaces (ドメイン サービスとリポジトリのインターフェイス)
• Domain.Services (ドメイン サービス インターフェイスの実装)

インフラストラクチャー

• Infrastructure.Data (EF を使用したリポジトリと作業単位の実装)
• Infrastructure.DependencyResolution (UnityによるIoCの実装)

UI

• UI.WebMVC

そして、ここに私の質問があります：

1-これらのレイヤーで正しいですか、それとも何か不足していますか?

2- 特定のテクノロジー (ロギングなど) に関連するサービスについては、そのインターフェースはどこにあるべきか (Domain.Interfaces または Infrastructure.Interfaces) ?

3-私が理解しているように、ドメインサービスは私のビジネスユースケースを処理します。アプリケーションサービスから得られる利点は何ですか

4- Domain Service と Application Service の違いは何ですか? また、Application Service インターフェイスはどのプロジェクトに配置する必要がありますか?

5- ユーザー認証プロセスは、アプリケーション サービスまたはドメイン サービスの一部にする必要がありますか?