当我使用实体代码首先创建我的数据库时，如果我在asp.net中创建MVC 4项目，我应该使用什么命名约定。我想说清楚的是，实体模型不是MVC模型。例如，我应该有一个名为Project的类，它定义了EF将使用的属性，然后创建一个名为ProjectModel的MVC模型。我也将有viewModels，这将是有些不同，然后模型，将在' ProjectDashboardViewModel的形式。在建立这样一个项目时，对于命名约定有什么建议?
您已经有了问题中表达的强命名约定。我用的是完全一样的:)
- 域模型不带前缀-
Project -
Model后缀的mvc类不完全是视图模型-ProjectTableRowModel -
ViewModel后缀用于视图模型-ProjectDetailsViewModel
不幸的是，像这样的问题可以有很多答案，没有真正的事实标准，但我是这样做的。
首先，我创建一个空的解决方案，我们将其命名为MyProject。然后，我向这个解决方案添加一个名为MyProject的类库(我喜欢在根命名空间中拥有域)。这个类库将包含某些文件夹/命名空间，如下所示:MyProject
Entities
MyEntity1.cs
MyEntity2.cs
Database
MyContext.cs
然后我添加一个MVC项目到我的解决方案，称之为MyProject.Mvc。我在MyProject中使用ViewModels和DataTransferObjects。Mvc，并使用AutoMapper使用我的实体来构造它们。对于每个视图，我都有一个ViewModel，所以假设我有一个名为DashboardController的控制器和一个名为Overview的动作，那么我将为它专门创建一个DashboardOverviewViewModel对象。
将我的域分开的一个好处是，它变得更容易进行单元测试，在单元测试中，我将有相应的测试项目，称为MyProject。测试和 MyProject.Mvc.Tests 。
这篇文章作为ViewModel处理
最佳实践是将映射到数据库表的实体放置到解决方案中的单独类库中。
您的建议使用项目的DB模型和项目模型的MVC模型是适当的。
我认为你的ProjectModel实际上是一个ProjectViewModel，因为属性的选择以及如何填充它们主要是由表示需求驱动的。仅仅因为你可能没有项目视图，并不意味着你不能有项目视图模型。也许你的ProjectDashboardViewModel包含了许多ProjectViewModel对象
这都是为了更好的可读性和可维护性。
你可以为ViewModels创建一个库，比如SomeProduct.ViewModel.dll，然后在MVC web项目中引用它。在这个程序集中用"ViewModel"后缀类，比如RevenueViewModel/RegisterViewModel。还可以在这个项目中创建命名空间，以模块方式组织视图模型。
对于实体，您可以创建另一个库，例如SomeProduct.Entities.dll，并在MVC web项目中引用该程序集。再次有效地使用名称空间来组织程序集中的对象。你可以用"Model"作为这些对象的后缀