問題タブ [onion-architecture]

私はタマネギアーキテクチャのこの実装に基づくアーキテクチャを使用しています。NHibernatesのデフォルトのロガー（log4net）をNLogに変更することに挑戦することにしました。NLogの構成方法は理解していますが、LogerFactoryクラスのロガーの依存関係を解決するのに問題があります。現在、私のNHibernateプロジェクトは私のロギングインターフェイスしか知りません。NHibernateプロジェクトで依存関係を解決するにはどうすればよいですか？

これが現在の私のプログラム構造です。コンソールアプリはninjectを初期化し、LoggingModuleやRepositoryModuleを含むモジュールをセットアップします。リポジトリから何かが初めて必要になると、SessionHelperクラスがセッションを構築し、NHibernateを構成します。これは、NHibernateが私のLoggerFactoryを呼び出す場所です（LoggerFactoryはNHibernates ILoggerFactoryを実装します）。NHibernateはLoggerFor（Type type）;を呼び出します。タイプはNHibernate.Cfg.Configurationとして渡されます。ここから、ILoggingServiceを介してNLogのインスタンスを取得する必要があります。これは、混乱しているところです。ここでこの依存関係を解決するにはどうすればよいですか？私のコンソールアプリは、カーネルを構築してモジュールをロードした場所であるため、解像度を認識しています。ここに別のカーネルを設定するだけですか？これを解決するための最良の方法は何ですか？

編集：これが私の現在のコードです：

Program.cs

LoggingModule.cs

RepositoryModule.cs

RepositoryBase.cs

SessionHelper.cs NHibernateセッションを構築し、構成します。connectionStringが挿入されていることに注意してください。ここにロギングサービスを簡単に挿入できます。

LoggerFactory.csNHibernateがロギングに使用するようにapp.configを介して構成されます。これは、依存関係の問題が発生している場所です。これはNHibernateと一緒に住んでいます。ここでNLogを簡単に参照して、NHibernateに接続できますが、NHibernateが使用しているロギングフレームワークを気にしないようにします。これが、自分のインターフェースのみを扱い、Ninjectに具体的な実装を注入させたい理由です。

現在のプロジェクトでは、DDD / オニオン アーキテクチャをますます採用しています。私がまだはっきりしていない多くのことの 1 つは、どの程度のカプセル化が必要かということです。具体例でわかりやすく説明。

例

質問

エンティティの工場については、

1. 呼び出し元が値オブジェクトを構築し、それを使用して ComplexEntity を初期化することを期待しますか?
2. 基本的に CLR の基本型をファクトリに渡し、エンティティを構成するすべての ValueObject を作成しますか?

私はオプション 2 に傾いていますが、それを裏付ける文献が見つからないようです。

編集 1

正直なところ、私はまだはっきりしていません。集約ルートはどうですか？

my entity が他のエンティティを参照する場合 (例: 以下)。

1. IComplexEntityFactory,が必要ILessComplexEntityFactoryですか? またはIComplexEntityAggregateFactory、 LessComplexEntity を作成し、 ComplexEntity をインスタンス化するだけですか?
2. AggregateFactory ソリューションの場合、ファクトリに渡された LessComplexEntity 属性が既存の LessComplexEntity に対応する場合はどうすればよいですか? リポジトリから取得して再利用しますか? それとも、呼び出し元にエラーを返しますか?

3. AggregateFactory のメソッド シグネチャは何ですか? (ValueObject a, ValueObject b)、または(ValueObject value, LessCompelxEntity entity)

   public class ComplexEntity { プライベート readonly int _id; public int Id { get { return _id;} }

   }

   public class LessComplexEntity { プライベート readonly int _id; public int Id { get {return _id;} } public ValueObject 値 {get; set;} public LessComplexEntity(int id, ValuObject value) { } }

Web リクエストごとにセッションを処理するように NHibernate を設定しようとしています。リポジトリが使用されたときにセッションを初期化するプロジェクトがあります。Web リクエストごとにセッションを管理する最良の方法を知りたいです。私のアーキテクチャは分離されているため、Web プロジェクトでセッションを開いたり閉じたりすることは避けたいと思います。Web プロジェクトに NHibernate の存在を知らなくても、これを処理する良い方法はありますか?

これは私のリクエストフローです:

Web リクエスト -> ASP.NET MVC 3 -> コントローラー -> サービス -> リポジトリ (セッションを開く) -> NHibernate -> データベース -> MVC に戻って外に出ます。

私はService-Repository-UnitOfWorkパターンと呼ばれるものを使用してMVCアプリを作成してきました。これは、次のようになります。

MVC Controllers --> Services --> Repositories --> EntityFramework

その後

Repositories/EntityFramework (constructs Domain Objects/POCO) --> Services --> Transform to ViewModels --> Controller --> Send the ViewModel/View to the client.

IoCコンテナーを使用して、さまざまなコンポーネントのコンストラクターに注入されるサービス、リポジトリー、およびUnitOfWorkのインターフェイスを構成します。

私の質問は、これはオニオンアーキテクチャにまったく似ているのでしょうか？

それは意味がありますか？

私は自分のアーキテクチャで認証用のパスワードをハッシュするのに最適な場所を見つけようとしています。これが私のリクエストフローです。

私はサービスレベルとリポジトリレベルでのハッシュの間で引き裂かれています。私は両方の利点を見ていますが、誰かがこれを処理するための標準的な場所を知っていますか？ハッシュパスワードをデータベースに保存しています。

アーキテクチャ内の依存関係の問題を解決する方法を理解しようとして問題が発生しています。私はNHibernateを使用しており、そのICriteriaインターフェイスを独自のICriteriaItemインターフェイスで抽象化しようとしています。ICriteriaItemは私のリポジトリインターフェースで使用されています：

ICriteriaItem.cs

IUserRepsository.cs

私のサービスレイヤーは、AccountServiceでこのリポジトリを使用しています

AccountService.cs

私の問題は、NinjectでCriteriaItemのインスタンスを取得することです。すべてのバインディングはMVCレイヤーで行われ、現在、サービスレイヤーはNinjectについて何も知りません。私のサービスはすでにコンストラクターに注入されています。だからここに私のオプションがあります：

1. ICriteriaItemをコンストラクターに挿入するだけです。すべてのサービスでこれが注入されるため、これは汚い感じがします。ベースリポジトリでこれを行うことができると確信していますが、それでも汚い感じがします。

2. カーネルを注入し、それをサービスで使用してICriteriaItemのインスタンスを取得します。さらに気分が悪くなります。

3. ICriteriaItemの具象クラスを公開し、インターフェースを廃止するだけです。

4. 別の方法を見つける...

考え？私はこれですべて間違っていますか？もっと良い方法はありますか？ここで何が欠けていますか？

Onion Architectureと MVCについていくつか質問があります。

1) ドメイン サービスとアプリケーション サービスの違いは何ですか?
2) Service/Repository/UnitOfWork パターンはこのアーキテクチャにどのように適合しますか?
3) このアーキテクチャは MVC アプリケーションの良い計画だと思いますか?

これについてのご意見は大歓迎です。

新しいアプリケーションでは、タマネギのアーキテクチャに従うことを計画しています。

ソリューションの階層は次のとおりです

• ドメイン-サービスとリポジトリのすべてのインターフェースが定義されている場所。
• インフラストラクチャ-これは、すべてのデータアクセスが配置されるレイヤーです。これらのクラスは通常、ドメインで定義されたインターフェースを実装します。
• Web-これはアプリケーションの私のプレゼンテーション部分です。同じレイヤー内に、ドメインで定義されたサービスを実装するための別のフォルダーがあります。

私の計画は、依存性の解決に依存性注入を使用することです。当初、私はDI関連のコードをインフラストラクチャに配置することを考えました。しかし、問題は、サービスをマップするときに循環参照につながることです。実際のサービスの実装は私のWebプロジェクトにあり、Webプロジェクトはすでにインフラストラクチャを参照しているためです。Onion Architecture（推移的な依存関係）の原則に違反しているため、具体的なサービスを別のレイヤーに移動することはできません。

どんなリードでも大歓迎です。

2部構成の質問...主に文字列の翻訳のためにソリューションで使用されるいくつかのリソースファイル（.resx）があります。たとえば、Errors.resx、Validation.resx、およびEnums.resxです。

パート1： Enumsリソースファイルがない場合は、すべてのリソースファイルをUIレイヤーに配置し、おそらくそれ自体のアセンブリ（'Company.App1.MVCApp.Resources'など）内に配置して、 Webアプリ（Company.App1.MVCApp）...リソースファイルをUIレイヤーに配置するのは正しいでしょうか？

パート2：Enums.resxファイルには、列挙型メンバーに関連付けられた記述文字列が含まれています（Description属性を使用）。UIおよびドメインサービスでは、おそらく翻訳時に記述文字列にアクセスする必要があります。これをコア/ドメインレイヤーのどこかに、Company.App1.Core.Resourcesのような場所に保存することを考えました...？または、適切なOnionアーキテクチャに固執するために、コアレイヤーで抽象化を作成してから、インフラストラクチャレイヤーのどこかにResourcemManagerを実装する必要があります。

Jeffrey Palermo から有名な Onion Architecture を学んでいます。このパターンに固有のものではありませんが、リポジトリとドメイン サービスの分離が明確にわかりません。リポジトリはデータ アクセスに関係し、サービスはビジネス レイヤーに関するものであると (誤解して) 理解しています (1 つ以上のリポジトリを参照します)。

多くの例では、リポジトリには や などの背後にある種のビジネス ロジックがあるようGetAllProductsByCategoryIdですGetAllXXXBySomeCriteriaYYY。

リストの場合、サービスはロジックのないリポジトリのラッパーにすぎないようです。階層 (親/子/子) の場合、ほぼ同じ問題です: 完全な階層をロードするのはリポジトリの役割ですか?