MVC中的View是否应该知道Model数据？

Question

我已经研究了一段时间的MVC，类似这样的问题（这个）和（这个）。

然而，它们没有回答我的问题。在许多MVC示例中（包括ASP.NET MVC和JAVA MVC），他们通常为模型提供字段，例如（名字，年龄等），然后允许视图“读取”这些字段。

但是，从我所理解的来看，视图不应该知道模型，因为如果视图知道模型，则其封装就不正确。

然而，图片显示视图知道模型以显示正确的数据。

如果我理解正确，那么模型可以是系统的业务逻辑，视图不应与之连接。

假设我的模型从数据库获取数据，那么仍然是我的模型是我的业务逻辑，而不是数据库，或者我想错了吗？

所以我的问题是

• 视图是否需要知道模型以使用正确的数据？
• 控制器的工作是从例如数据库中获取数据并从中创建模型，然后视图应该使用模型数据进行显示吗？
• 什么是模型业务逻辑？（请不要使用字段来解释）

- Bojje

---

我喜欢将我的用户界面分为三个部分（模型、视图、控制器）。它们只构成应用程序的顶层，下面是业务逻辑层和持久化层。因此，在MVC中，模型仅仅是UI的一个模型，从这个角度来看，视图确实需要了解模型。 - Dave Becker

Answer 1

很多内容都是开放解释的。有许多方法，取决于哪个最适合您。如果可以帮助的话，以下是我的方法。

视图是否需要了解模型以使用正确的数据？ 是的。当渲染时，视图具有一个模型导入指令，用于绑定到它正在访问的模型。如果视图不知道它正在访问的模型，则如何绑定数据呢？

控制器的工作是从数据库等地方获取数据并创建模型，而视图应该使用模型数据进行显示吗？ 不，控制器不应该知道数据层实现的任何信息。控制器的唯一工作应该是调用所需的服务来构建视图模型。

什么是模型业务逻辑？（请勿使用字段来解释） 关于“模型业务逻辑”的确切术语不太确定。模型可用于描述领域模型或在此情况下的视图模型。业务逻辑是您对由某些服务填充的业务或领域模型对象执行的操作。

就像你说的那样，我处理ViewModels和业务逻辑的方式是将领域模型（例如客户或订单）分离到单独的dll中，并通过服务填充这些领域对象。然后，您的View Model成为领域模型对象的组合。

因此，控制器向消耗数据层的服务发出调用，这些服务将返回填充的领域对象。然后可以使用这些对象来填充您的视图模型，然后由视图使用。

我添加了下面一个非常简单的方法，希望能为您指明正确的方向。

public class MyController
{
    [HttpGet]
    public ViewResult GetCustomer(int customerID)
    {
        var myViewModel = new CustomerViewModel();
        var myService = new MyServiceLayer();

        var myCustomerDetails = myService.GetCustomerDetails(customerID);

        myViewModel.Customer = myCustomerDetails;

        return View("CustomerDetails", myViewModel);
    }
}

public class CustomerViewModel
{
    public CustomerDomainObject Customer { get; set; }
}


public class CustomerDomainObject
{
    public string Name {get;set;}
}

public class MyServiceLayer
{
    public CustomerDomainObject GetCustomerDetails(int customerID)
    {
        var myCustomer = new CustomerDomainObject();
        var dataLayer = new MyDataLayer();
        var myCustomerData = dataLayer.GetCustomerDetails(customerID);

        var myDataRow = myCustomerData.Tables[0].Rows[0];
        myCustomer.Name = myDataRow["Name"].ToString();

        return myCustomer;
    }
}

public class MyDataLayer
{
    public DataSet GetCustomerDetails(int customerID)
    {
        //Execute proc etc...
        return new DataSet();
    }
}

- Wheels73

---

当你在一个单独的dll中表示客户或订单，并且这些领域对象由服务填充时，你所指的服务类型是什么？只是为了让我对此有个感觉。 - Bojje

一个商业类（如果您愿意）可以坐在一个单独的类库项目中。它将使用数据层从数据库中获取所需的数据。然后，它可以用数据库数据填充领域对象并传递回控制器。 - Wheels73

我已经编辑了我的答案，并提供了一个简单的示例来证明原则。 - Wheels73

这对我来说是非常大的帮助。谢谢。 - Bojje

Answer 2

在ASP.NET MVC中，您拥有强类型视图。这是一个剃刀的东西，让您在构建视图时轻松访问模型属性。每当您尝试访问像@Model.Name这样的属性时，智能感知都会起作用，您很容易就能注意到这一点。至于是否应该使用强类型，我认为这取决于您的需求，使用强类型视图没有任何缺点。它将在编写视图时帮助您节省大量时间，并且您肯定会减少运行时错误。

对于“模型业务逻辑”，我想说您肯定可以在模型中拥有很多逻辑，但这并不像听起来那么简单。您可能需要使用模式并拥有负责一件事情的小类。

请查看此链接：https://msdn.microsoft.com/en-us/library/hh404093.aspx

- NicoRiff

Answer 3

一般来说，将领域模型与其视图表示完全分离是一个好主意。领域模型包含整个业务逻辑，可能非常复杂。此外，表示层通常需要极其简化的对象（仅为数据结构，没有任何业务逻辑）。特定的视图技术可能对对象施加严格限制。除此之外，我们经常更改/聚合领域对象以满足最终用户的特定需求（通过创建专门的DTO）。因此，由于表示层和领域层如此不同（领域模型不应依赖于视图），我经常完全将它们分开。这样可以创建更灵活的设计。

- Mike Wojtyna