5

私はASP.NETMVCを数か月使用していますが、プロジェクトのソリューションのレイアウトにはまだ満足していません。私は、可能な限りポータブルで再利用可能な中規模のWebサイトCMSを構築しようとしていますが、その設計には明らかな問題がいくつかあります。関心の分離を考慮して、ソリューションをどのように構成すべきかについてのアドバイスを探しています。私はここで同様の質問を見つけましたが、それは私が直面している問題のいくつかを実際には対象としていません。

現在、これが私のソリューションのレイアウトです。

+Project.Controllers-すべてのコントローラークラス
P + roject.Controllers.Tests

+ Project.Core-反復タスクといくつかの構成ハンドラーを含むユーティリティクラス（このプロジェクトはより具体化する必要があります）
+ Project.Core.Tests

+ Project.Models-モデルクラス、Entity Frameworkコンテキスト、およびリポジトリクラス
+ Project.Models.Tests

+Project.Web-すべてのビューとコンテンツ

私が現在見逃している主なことの1つは、ビジネスロジックを固定する場所であり、リポジトリクラスにビジネスロジックを誤って配置しているだけでなく、コントローラーアクションに混在させていると感じています。明らかに、私はこの問題をよく知っています。そのソリューションレイアウトのどこにビジネスロジックを配置すべきかがわかりません。ソリューション構造を変更する必要がありますか、それともモデルプロジェクトでそのビジネスロジックを安全に維持できますか？また、EFコンテキストがModelsクラスにあることは本当に好きではありませんが、モデルに必要なエンティティクラスからデータレイヤーコードを分離する方法がわかりません。

他のすべての人は、本番ASP.NET MVCソリューションをどのようにレイアウトしていますか？

4

3 に答える 3

4

S＃arpアーキテクチャプロジェクトが使用するレイアウト、またはCode CampServerMVCリファレンスアプリケーションで使用されるオニオンアーキテクチャを確認することをお勧めします。どちらのプロジェクトも、asp.net MVCとドメイン駆動設計のコンテキストで懸念事項を適切に把握するために、さまざまな人々によって多大な努力が払われてきました。

于 2009-08-25T15:55:27.600 に答える
1

個人的にはMVCを学んでいるだけです。私の経験はASP.NETWebFormsからのものですが、提供されたリンクで提案されているレイアウトを使用します。2番目の答えは次のとおりです。

  • モデル
  • ビュー
  • コントローラ
  • サービス
  • テスト-プロジェクトごとに1つ。
于 2009-08-25T15:53:29.070 に答える
0

EFコンテキストとリポジトリをモデルからデータアクセス層Project.Dataに取り出し、ビジネスオブジェクトをProject.BusinessLogic（？）に配置します。

これにより、2つのアセンブリ（Project.DataとProject.BusinessLogic）を、同じドメインで構築する可能性のある他のアプリに配置できるという利点があります。つまり、次のプロジェクトには非常に便利な出発点があります。

お役に立てば幸いです。

ダン

于 2009-08-25T15:56:27.537 に答える