サービスレイヤーとリポジトリレイヤーを備えたASP.NET MVC、インターフェイスはどこに定義する必要がありますか？

Question

私は、リポジトリレイヤーとサービスレイヤーを備えた.NET MVCアプリケーションのかなりシンプルなレイヤードアーキテクチャを決定する過程にあります。私はいくつかのかなり明確で簡単な例を見つけました、特に www.asp.net, 、そしてここでいくつかの質問と回答がありますが、私は少しシンプルで、小さなアプリケーションに適したものを探していますが、それは異なるプロジェクトを使用してアイデアを伝えます。上記にリンクした例には、モデルの名前空間のクラスとしてリポジトリとサービスがあります。それは私がそれを適切に説明できるようにするためには、明確な分離ではありません。

Interface IrePositoryを実装するリポジトリ用の別のプロジェクトがあります。 ISERVICEを実装し、IREPOSITORY（コンストラクタインジェクション）を取得するサービス用の分離プロジェクトがあります。サービスはISERVICEを実装します。この例には、コントローラーがサービスをインスタンス化するだけで十分であり、IOCコンテナはまだ必要ありません。それを、依存関係の注入と場合によってはより多くの層を含むように徐々に構築するシーケンスの一部である、最高の建築慣行を理解するための中間ステップと考えてください。

問題は、IrePositoryとIserviceをどこで定義すればよいですか？もちろん、サービスプロジェクトとリポジトリプロジェクトの両方がそれらを参照する必要があります。サービスプロジェクトとリポジトリプロジェクトの両方が参照する別のプロジェクトで定義されるべきであることは明らかです。もしそうなら、良い命名条約は何でしょうか？ xxxxcontractsのようなもの？

同様に、プレゼンテーション、サービス、リポジトリレイヤーの間に渡されたデータモデルの場合、すべてのレイヤーで参照されるxxxxmodelsと呼ばれる個別のプロジェクトを持つことは許容できますか？場合によっては、サービスレイヤーとリポジトリレイヤー間に渡されるモデルがサービスレイヤーとプレゼンテーションレイヤー間で渡されたモデルとは異なる場合がありますが、原則は同じです。

ここでも同様の質問に対する答えを見つけましたが、ここで概説したものよりも複雑なアーキテクチャが含まれる傾向があります。データレイヤーを参照し、コントローラーにビジネスロジックを持っている上記のステップ1または2つとして見ることができる2つのレイヤーの非常にシンプルでクリーンなイラストを実現したいと考えています。本格的なベストプラクティスにまっすぐ進むための強力で有効な議論があることは知っていますが、誰もが一度にジャンプするのに適しているわけではありません。

Answer 1

序章

これは私も自問したことです。私がいつも持っている燃えるような質問の1つはあなたのものに似ています。

良い命名条約は何でしょうか？

物事にどのように名前を付けるべきですか？彼らはフォルダーやプロジェクトに行くべきですか？

周りを検索した後、答えはそれだと思います それは本当に重要ではありません. 。重要なことは、あなたのソリューションにはいくつかの賢明なアーキテクチャがあり、あなたが 個体.

このトピックに関する私のASP.NET MVCヒーローはそうです ジェフリーパレルモ, スティーブ・スミス と ジミー・ボガード.

オニオンアーキテクチャ

ジェフリー・パレルモは古いアイデアの組み合わせについて議論しますが、それらを一緒にして、視覚的に刺激的な名前を与えます オニオンアーキテクチャ （推奨される読み取り）。ジェフリーは、物事をどこに置くかという問題に対する良いアプローチを示しています。彼はあなたのアプリケーションの中心（または上部）であなたがあなたを持っていると説明しています 芯. 。このレイヤーは、次のようなインターフェイスを配置する必要があります IRepository と IService.

ほとんどすべてのインターフェイスはコアに移動する必要があり、他のすべて（他のプロジェクト）はすべてコアを参照できます。これにより、すべてが実装の詳細を知らずにアプリケーションの骨格構造を知っています。

UIレイヤーの参照をできるだけ（理由で）参照してください。私のアプリケーションの1つでは、私のUI（MVC）レイヤーはコアのみを参照しています。必要なものはすべて、それに注入されます 依存関係インジェクション.

スティーブ・スミスは、オニオンアーキテクチャと同様のアイデアについてデモンストレーションで議論します MVCソリューションベストプラクティス：ソリューション問題の解決策

私の解決策

私のMVCソリューションでは、このような典型的な構造があります。

• myproject.core
• myproject.domain
• myProject.dependencyInjection
• myproject.infrastructure
• myproject.web
• myproject.tests

芯 インターフェイスが含まれています。通常、サービス、モデル、ドメイン、リポジトリなどのフォルダーに分割されます。

ドメイン レイヤーはコアのみを参照し、私の実装を含みます。コアのドメイン抽象化のための多くのコンクリートクラスを提供します。多くのビジネスロジック、処理、コマンド処理、マネージャークラス、具体的なサービスの実装などを扱っています。私はそれをかなり内なる層と考えているので、できるだけ参照していません。

依存指示 レイヤーには、選択したDIパッケージ/フレームワークと実装の詳細が含まれています。私はそれを外層と考えています。 UIまたはインフラストラクチャと同様に、多くのことを参照しても大丈夫です。このレイヤーが別のプロジェクトになる必要はなく、多くの人がこれをしないようにあなたに言うでしょう。それで大丈夫です;プロジェクトの複雑さに役立つことをしてください。私は自分のDIがそれ自身のものであることが好きです。それが非常に分離されていることの良いところは、DIフレームワークを別のものに置き換えることができ、物事はうまくいくでしょう。 DIプロジェクトを参照するレイヤーはありません。

インフラストラクチャー レイヤーには、ロギング、電子メール、データアクセスに関する情報が含まれています。それには私が含まれます orm 選択の。それはビジネスロジックのものではなく、UIのものでもありません。物事を成し遂げるのは私の解決策の鉄道です。外側の層にありますが、コアのみを参照しています。

ウェブ レイヤーは私のMVCプロジェクトであり、コアのみを参照しています。

複雑さと最終的な考え

ここで同様の質問に対する答えを見つけましたが、ここで概説したものよりも複雑なアーキテクチャを含む傾向があります

それは良い点です。問題の複雑さに留意することが重要です。しかし、優れたソリューションの実践に阻止されないでください。私のソリューションとオニオンアーキテクチャは必ずしも非常に複雑ではなく、ソリューションを実際に膨らませません。彼らはただ物事を分離したままにします。

の 進化プロジェクト構造, 、ジミー・ボガードは、物事が過度に複雑であることについて語っています。私が言ったことが複雑すぎると思われる場合は、ジミーのアドバイスに従って、すべてを1つのプロジェクト（UIレイヤー）に入れてください。それは大丈夫です - それがあなたに合っている限り。

私の解決策をアイデアとしてのみ取り入れることを忘れないでください - 考慮すべきこと。私のアプローチは、最高の賢者のアドバイスに従う試みですが、私はそれほど成功しただけだと確信しています。私はまだ改善することができます（そして必要です）。