了解 MVC 中的模型类与数据类答案

【问题标题】：Understanding Model Class vs Data Class in MVC了解 MVC 中的模型类与数据类
【发布时间】：2017-10-26 04:42:24
【问题描述】：

多年来，我使用 Webforms 开发了 ASP.Net 应用程序，并且我已经完成了一些 MVC 应用程序，但从未真正完全使用过该框架，这是由于大多数项目的时间限制。虽然，我使用的是 MVC 结构，但我仍在使用旧方法，即不使用 @Html.BeginForm 等，而是使用标签等。

我最近刚刚开始另一个项目，但这次我想使用正确的 MVC 功能。

我一直在阅读设计模式中的最佳实践。在我的解决方案中，我有 MVC 应用程序、测试和数据（这是一个连接到数据库的类库）的项目。我没有使用实体框架，但我仍然想知道为视图模型创建类的正确方法。

在我的数据库类中，我有一个名为 Users 的类

public class User
{
    public long Id { get; set; }

    [Required]
    public string Name { get; set; }

    [Required]
    public string Email { get; set; }

    [Required]
    public long RoleId { get; set; }
}

我想在视图上呈现的字段是名称、电子邮件和 RoleId 的下拉列表。那么对于视图上的模型，它不必与我的数据类相同是否正确？是否低于正确的模型视图类？

public class UserModel
{
    public Data.User User { get; set; }

    public IEnumerable<KeyValuePair<long,string>> RoleList { get; set; }
}

询问的原因是，最初，我总是假设 Model 类应该与我在 Google 中读到的 Data 类相同，但在大多数情况下并非如此。这是正确的吗？

这是视图的正确实现吗？

@using (Html.BeginForm())
{
   @Html.LabelFor(m=>m.User.Name)
   @Html.TextAreaFor(m=>m.User.Name)
   <br/>
   @Html.LabelFor(m => m.User.Email)
   @Html.TextAreaFor(m => m.User.Email)
   <br />
   @Html.LabelFor(m => m.User.RoleId)
   @Html.DropDownListFor(m => m.User.RoleId, new SelectList(Model.RoleList, 
    "Value", "Key"),"--Please Select--")
}

【问题讨论】：

标签： asp.net asp.net-mvc model

【解决方案1】：

Model 类代表应用程序的业务方面，因为在您的情况下，您有一个 UserModel 类，其中包含用户信息和带有角色的集合，其中 Data Model 特定于存储库，即您的情况下的数据库表，因此数据模型通常表示我们拥有的数据库表。希望有道理。

你也可以参考下面的帖子，我认为类似的问题：

https://stackoverflow.com/a/2446051/1875256

【讨论】：

感谢@Ehsan 的快速回复。在我的示例中，在我的 "UserModel" 模型视图 类中使用 "User" Data Class 是否正确，或者我应该创建 "User" 的副本" 数据类 在我的 MVC 项目中，然后在模型视图上使用它？这是否意味着我的例子是正确的？谢谢。
这取决于，如果您需要在视图中访问所有属性，那么您可以重用现有的，但如果您需要添加更多属性或删除一些属性，以便它们不应该在 mvc 中公开项目，那么您将不得不创建一个单独的项目。

【解决方案2】：

您可以采取的最佳方法是为您想要公开数据/捕获数据的每个视图创建一个模型（新类）。这可以说是更多的工作，但它确实有一些巨大的优势。首先，您最终不会将视图与域紧密耦合，即您的用户表可能有 20 列，但您只想将 2 列公开给登录页面（用户名/密码）。其次，特别是通过 MVC 框架和 razor，您可以在验证（服务器端和客户端）以及显示名称等方面获得很大帮助。此外，关于管理您的依赖层次结构，您不希望在所有域模型中都引用 System.Web.MVC aarrrgh!!

“更多工作”部分出现在控制器中，您需要验证您的视图模型，然后将模型对象转换为域对象，以便您的业务类从那时起都使用一致的域模型。

就你的模型类提案而言，我会更像这样

public class UserModel
{
    [Required]
    [Display(Name = "Name")]
    public string Name { get; set; }

    [Required]
    [DataType(DataType.EmailAddress)]
    [Display(Name = "Email Address")]
    public string EmailAddress { get; set; }

    [Required]
    [Display(Name = "Roles")]
    public IEnumerable<KeyValuePair<long, string>> RoleList { get; set; }
}

正如您在上面看到的，因为我有一个可以完全支持视图的粒度模型（而不是对 User 对象的引用），我现在可以根据需要为每个字段添加特定的验证

我确信有很多更好的理由走这条我现在想不到的路线，但我认为这会让你沿着正确的路线思考。快乐的编码。

【讨论】：