Entity Code First を使用してデータベースを作成する場合、asp.net で MVC 4 プロジェクトを作成する場合、どの命名規則を使用する必要がありますか? エンティティ モデルが MVC モデルではないことを明確にしたいと思います。たとえばProject
、EF が使用するプロパティを定義する という名前のクラスを用意してから、 という名前の MVC モデルを作成する必要がありますProjectModel
。また、`ProjectDashboardViewModel. このようなプロジェクトを設定する際の命名規則の推奨事項は何ですか?
4 に答える
問題で表現されている強力な命名規則が既にあります。私はまったく同じものを使用します:)
- ドメイン モデルのプレフィックスなし -
Project
Model
ビューモデルではない mvc クラスの接尾辞 -ProjectTableRowModel
ViewModel
ビュー モデルのサフィックス -ProjectDetailsViewModel
残念ながら、このような質問には多くの答えがある可能性があります。実際には事実上の標準はありませんが、私がしていることは次のとおりです。
まず、空のソリューションを作成します。それをMyProjectと呼びましょう。次に、 MyProjectという名前のクラス ライブラリをこのソリューションに追加します(ルート名前空間にドメインを配置するのが好きです)。このクラス ライブラリには、次のような特定のフォルダー / 名前空間が含まれます。
MyProject
Entities
MyEntity1.cs
MyEntity2.cs
Database
MyContext.cs
次に、ソリューションに MVC プロジェクトを追加し、 MyProject.Mvcと呼びます。MyProject.Mvc内でViewModels
andを使用し、 AutoMapperを使用してエンティティを使用してそれらを構築します。私はすべてのビューを持っているので、呼び出されたアクションで呼び出されたコントローラーがあるとしたら、そのためのオブジェクト があります。DataTransferObjects
ViewModel
DashboardController
Overview
DashboardOverviewViewModel
ドメインを分離する利点の 1 つは、単体テストが容易になることです。これにより、 MyProject.TestsおよびMyProject.Mvc.Testsという対応するテスト プロジェクトが作成されます。
ベスト プラクティスは、データベース テーブルにマップするエンティティをソリューション内の別のクラス ライブラリに配置することです。
DB モデルに Project を使用し、MVC モデルに ProjectModel を使用するという提案は適切です。
プロパティの選択とそれらがどのように設定されるかは、主にプレゼンテーション要件によって決まるため、ProjectModel は実際には ProjectViewModel であると私は主張します。Project View を持っていないからといって、Project ViewModel を持てないわけではありません。おそらく、ProjectDashboardViewModel には多くの ProjectViewModel オブジェクトが含まれています。
読みやすさと保守性の向上がすべてです。
SomeProduct.ViewModel.dll などの ViewModels 用のライブラリを作成し、これを MVC Web プロジェクトで参照できます。このアセンブリのサフィックス クラスに「ViewModel」を付けます。たとえば、RevenueViewModel/RegisterViewModel とします。また、このプロジェクト内に名前空間を作成して、ビュー モデルをモジュールごとに整理します。
エンティティの場合は、SomeProduct.Entities.dll などの別のライブラリを作成し、MVC Web プロジェクトでこのアセンブリを参照できます。ここでも名前空間を効果的に使用して、アセンブリ内のオブジェクトを編成します。これらのオブジェクトの末尾に「Model」を付けることができます。