Question

我已经阅读了一些关于MVC的文章，但有一件事我不清楚。该模型在实际中的作用是什么。

模型是否代表业务对象？或者它只是一个帮助从控制器向视图发送信息的类？

举例说明两个业务类（从数据库填充的数据）

Class Image
    Property FileName As String
    Property CreatedBy As User
End Class

Class User
    Property UserName as String
End Class

“Image”会成为模型还是我应该创建一个新类？

在模型中，我应该创建一个UserName属性来从User对象中获取它的数据吗？

Class ImageModel
    Property FileName As String
    Property CreatedBy As User

    ReadOnly Property UserName As String
        Get
            Return User.UserName
        End Get
    End Property
End Class

Answer 1

对此有很多看法，但根据我的经验，Model有两个主要观点：

视图模型

这是一个POCO，它只包含显示View所需的所有数据。数据通常由Controller填充。

胖模型，瘦控制器

Model完成了大部分业务工作。它包含并填充View所需的所有数据，并由Controller用于保存数据等。

MVC的美丽

MVC的魅力在于它是开放的！您可以选择所需的任何类型的模型...您可以将所有数据放入ViewState，放入Model，放入包含一堆ViewModel的{{1}}无论如何。这完全取决于你。模型，视图和控制器是空白的画布，可以随意使用。

我使用的是什么

我的团队已经做了很多MVC工作，我们已经尝试了很多这些不同的方法。我们最终决定我们最喜欢的是 Fat Model，Skinny Controller 范例我相信这种模式是“保持简单”和“不重复自己”的最佳模式，它肯定会保持“关注点分离”。
以下是我们的代码组织方式：

控制器
- 处理与HTTP请求有关的所有内容 - 重定向，身份验证，网络安全，编码等。
- 将所有“输入”提供给Model，并将Model提供给视图。不访问业务层或数据层。
观
- 处理所有HTML和JSON生成
- 仅访问强类型Model
模型
- 负责进行所有更新，调用业务和数据层，加载所有数据
- 处理所有验证和错误，并将这些返回给Controller
- 包含Model所需的所有数据的属性，并自行填充

尽管这听起来像是MVC的一般原则，但很快就会发现MVC不需要这些原则，这就是许多项目使用其他原则的原因。

实施例

以下是View的示例。 Controller创建它，它自己填充，Controller将它传递给View。

Model

在这种情况下，所有“用户业务逻辑”都在不同的项目（我们的“业务层”）中，因为我们有一个大型系统。但是较小的项目不需要这样......模型可以包含业务逻辑，甚至是数据访问代码。

Answer 2

有很多型号。它既可以是业务数据（或域）对象（Controller - ＆gt; Datasource，反之亦然），业务规则（对域对象起作用）或视图模型（Controller to View，反之亦然）。

您无需在ImageModel中再次明确定义用户名。

模型在MVC中的作用是什么？

2 个答案:

视图模型

胖模型，瘦控制器

MVC的美丽

我使用的是什么

实施例