C# 实体框架及其与MVC的关系

我试图了解整个MVC/EF关系。如果我创建了一个只与数据库交互的实体模型（因为您不应该将实体模型传递给视图），然后是模型的类，最后是视图模型，如下所示。我唯一的问题是，第二个类似乎是多余的，我所看到的示例中唯一的不同是，它们将数据注释应用于该类，因为它与视图交互。为什么确保实体对象不暴露在视图层上如此重要

我实际上还没有开始编写项目，但我假设您将使用实体模型与数据库交互，然后将其转换为ProductModel以传递给视图这是正确的逻辑吗

实体模型：

public class Product 
{
    [Key()]
    public int ID { get; set; }
    public string Name { get; set; }
    public string Description { get; set; }
    public double Price { get; set; }
}

型号：

public class ProductModel
{
    public int ID { get; set; }
    [StringLength(50)]
    [Required(ErrorMessage = "Product Name is required.")]
    [Display(Name = "Product Name")]
    public string Name { get; set; }
    public string Description { get; set; }
    public double Price { get; set; }
}

视图模型：

public class ProductViewModel
{
    Product myProduct { get; set; }\
    //Plus any other properties I may need for the view.
}

更新：

在我阅读的示例中，它们还有一个DBContext集，如下所示。那么ProductModel类是否无用呢

public class MyAppContext : DbContext
{
    public MyAppContext()
        : base("name=DBConnection")
    { 
    }

    public DbSet<Product> Products { get; set; }

 }

公共类MyAppContext:DbContext
{
公共MyAppContext（）
：base（“name=DBConnection”）
{ 
}
公共数据库集产品{get；set；}
}

我创建一个独立于实体的模型类有两个主要原因

正如您所提到的，属性。您可能希望在多个应用程序中重用您的实体，但它们可能不使用相同的属性。你不想用这些污染你的实体

根据它们的不同，您的实体可能需要一个基类。或者，可能存在必须应用于实体的属性或其他自定义设置。这可能会导致在测试业务逻辑时出现困难。此外，如果您更改了ORMs或ORM中的某些内容，您将使该更改与应用程序的其余部分隔离

---

基本上，您正在隔离应用程序的不同层，并保护一个层不受另一个层的更改。

您需要

产品类

，

产品视图模型类

，然后是

数据库上下文

。 如果你是第一次这样做，请阅读

或

他们有关于MVC的详细信息，两本书都有一个

真实应用程序教程，您可以从头到尾学习
，包括部署

您还将了解单元测试和其他MVC工具，如依赖项注入（Ninject）和Moq，为什么确保实体对象不在视图层公开如此重要？

事实并非如此。对于简单的CRUD控制器，只传入实体对象通常更容易。对于更复杂的页面，您可能同时与多个实体对象/类型进行交互。如何在不创建新模型类的情况下传递有关这两个对象的信息？
除了上述答案之外，还有一点没有提到，以防止数据发送到不需要修改的视图/客户端

例如，假设您的产品模型包含您向供应商支付的购买产品的价格。您不希望您的客户看到这些数据，但如果它包含在发送到视图的模型中，即使您不显示该字段，他们也可以对其进行评估。在这种情况下，您将使用不同的视图模型，并在将数据发送到视图之前将数据从ef/数据库模型复制到视图模型

有时，您可能会得到一个DBcontext类、一个EF/数据库类/模型和几个viewmodels，每个viewmodels都包含来自数据库模型的不同数据子集

您还可以使用一个保存多个数据库模型数据的viewmodel，您可以看到视图使用列表或下拉列表作为在viewbag中发送列表选项的替代方法。
有时，特别是在简单模型上，可能不需要视图模型。但是，还有一个很大的“但是”，我发现这种情况的例子很少，即使这样，我后来还是发现需要返回并创建一个视图模型。拥有专门的视图模型更安全、更简单、更容易

您可能会将其视为额外的工作，但可以从关注点分离的角度来考虑（这是MVC的全部要点）。例如，如果我想为输入显示SelectList，我可以将其添加到ViewBag或我的模型中。如果我将它添加到ViewBag中，我将丢失不理想的强类型，但它也不属于我的数据库跟踪实体。拥有一个视图模型，让我们把这些信息准确地放在它应该去的地方：一个强类型模型，它的存在是为了服务于视图，并且只服务于视图

或考虑验证：如果我需要数据库所需的字段（非null），但我想为用户选择这个字段，如果用户不指定，则在后台添加一些业务逻辑。视图模型可以轻松地处理这种抽象，而将其添加到实体本身将增加一个巨大的复杂性层
当然，不需要任何东西。您总是可以随心所欲地设置您的项目，但最佳实践是最佳实践是有原因的：与您一样的开发人员一次又一次地遇到相同的问题，并围绕一个可行的解决方案联合起来。你也许可以暂时避开视图模型，但最终，你会遇到同样的障碍，并将它们合并到一起，所以只要从一开始就做好，让你的生活更轻松
 首先，缺少了一些组合技术，一种是从所有其他层中完全提取DAL，这是一种技术。但也有其他技术可以使用；将“实体”类用作域类。在一个简单的场景中，我们总是使用业务层上的域类来应用所有业务规则。这将极大地帮助我们结合各层的可测试性，避免各层之间的无用链接，而不会增加