NHibernateとASP.NetMVCを使用しているプロジェクトがあります。このアプリケーションは、ユーザーが特定のデータを追跡し、入力されたデータに基づいて統計のビューを生成できるようにすることを目的としています。これまでのところ、私のアプリケーションの構造は次のようになっています。
NHibernateレイヤー：エンティティマッピング定義だけでなく、クラスもRepository<T>含まれます。UnitOfWork
コア/サービスレイヤー：ジェネリックEntityServiceクラスが含まれています。現時点では、これは単にトランザクションスコープを定義し、より高いレベルのデータアクセスサービスを提供するためIUnitOfWorkにインターフェースします。IRepository
プレゼンテーション層（MVCアプリケーション）：まだ実装されていませんが、通常のものと依存性注入が含まれています。
いくつか質問があります。
MVCアプリケーションがすべてのレイヤーの依存性注入を処理できるようにするのは貧弱な設計ですか？たとえば、
EntityServiceコントローラーへのインスタンスの依存性注入だけでなく、クラスIRepositoryへの依存性注入も処理します。EntityServiceこれは、2つの異なる場所で依存性注入を実行することを意味しますが、サービス層はこれ自体を処理する必要がありますか？統計はどこで作成すればよいですか？このビジネスロジックは、現在、エンティティタイプの定義と、エンティティのプロパティを変更およびアクセスするためのインターフェイスのみが含まれているサービスレイヤーに属していないようです。私はこれについていくつか考えていますが、どれが一番好きかわかりません：
- サービスレイヤーをそのままにして、別の統計プロジェクトを作成します。これは、使用されるエンティティタイプから完全に独立しています。つまり、MVCコントローラーは、ビジネスエンティティと（おそらく静的な）統計の間で生の数値情報を渡す必要があります。クラス。これは非常にきちんとした分離ですが、プレゼンテーション層にまだ多くのビジネスロジックが残っていることを意味する可能性があります。
- 統計プロジェクトを作成します。ただし、このプロジェクトのクラスと私のビジネスエンティティの間に緊密な結合を作成します。たとえば、
Readingオブジェクトの値をメソッドに渡す代わりに、オブジェクト全体を渡します（またはそれらを拡張メソッドとして定義します）。これにより、ビジネスロジックがMVCアプリからシフトしますが、緊密な結合は少し厄介なようです。 - すべてのビジネスロジックをサービスレイヤー内に保持します。の強く型付けされたサブクラスを定義し
EntityServiceます。これにより、私のサービスには、エンティティクラス自体を純粋なデータコンテナとして維持しながら、エンティティ固有のビジネスメソッドとデータストレージメソッドの両方が含まれます。一般的な統計処理用に別の統計プロジェクトを作成し、派生したサービスクラスを介してそのメソッドを呼び出します。私のサービスクラスは、ビジネス機能をによって作成されたストレージ機能と効果的にマージしIRepository<T>ます。
私は3番目のオプションに向かって間違っていますが、誰かが何か考えを持っていますか？別の提案？
前もって感謝します！