asp.net-mvc - ASP.NET 模型设计的概念

Question

首先，这是我学习 MVC 的第二周，我很好奇使用 MVC 设计更好的网站结构

在 ASP.NET MVC 框架中，强烈建议将大部分业务逻辑代码写入模型而不是控制器，我的问题是，这样做有什么好处？在控制器中操作数据不是很好吗？会不会占用更多的资源和时间？

欢迎任何想法。如果你有，请给我任何文章链接=]

Answer 1

@MystereMan 只是部分正确。在真正的 MVC 模式中，是的，所有业务逻辑都属于模型。我在这里不是在谈论 ASP.NET MVC，而是在谈论实际的抽象 MVC 模式。

在实践中，模型通常是数据库中表行的表示，因此很多时候将所有业务逻辑放在“模型”中是不切实际的，甚至是不可能的。在这个意义上，我们倾向于将主要由数据库支持的“模型”称为“实体”。该实体是您的数据库状态的“模型”（或在更新的情况下对该状态的更改）。从这个意义上说，添加其他未在数据库层中表示或适用于数据库层的逻辑并不真正合适。

这就是为什么大多数开发人员会添加所谓的“视图模型”，这个概念在某种程度上是从称为 MVVVM（模型-视图-视图模型）的模式中借用的。这种模式是 MVC 的替代方案，但两者并不相互排斥。换句话说，有可能，甚至多次建议将两者的概念混合和匹配成一种混合模式。

在 ASP.NET MVC 中，这通常表现为在现有 MVC 结构中添加“视图模型”。您的模型成为您的数据库支持的实体，视图模型将包含上下文中视图所需的模型数据的子集以及仅与所述视图相关的任何其他数据或逻辑，视图利用此视图模型来呈现自身和控制器仍然将一切联系在一起。

不过基本效果是一样的。视图模型本质上承担了 MVC 的“模型”的角色，是的，你所有的业务逻辑都应该放在这里。一个设计良好的视图将只有最少量的服务器端代码来呈现它；for 循环、简单的 if 语句等都可以，但计算则不行。控制器的工作只是返回响应，这意味着获取视图需要呈现的任何内容。它不应该知道您的数据，也不应该关心正在与哪些数据进行交互。它只是将获得的任何内容传递给视图并发送响应。

Answer 2

MVC 的重点是关注点分离——控制器不应该知道数据来自哪里，或者它是什么格式，或者需要应用什么逻辑来检索它。

模型的工作是向控制器提供数据；不多不少。好处是关注点分离——如果您将来需要更改业务逻辑，您只需在模型中更改一处即可。

在资源和时间方面，我不知道如果在控制器中进行数据操作，程序的效率必然会降低。但它可能设计不佳并且更难维护。

MVC维基百科文章是一个很好的起点。

Answer 3

那么，您将业务逻辑放在哪里？我已经为此苦苦挣扎了一段时间，并且根据应用程序的大小和复杂性提出了不同的位置。

小应用程序：使用数据注释将业务逻辑放在模型上，并为您无法通过注释实现的任何自定义规则实现 IValidatableobject 接口。

中型应用程序：构建一个服务层，您的服务对象在您的域模型上充当网关，并且可以验证任何业务规则。这是一个很好的资源：http ://www.asp.net/mvc/tutorials/older-versions/models-%28data%29/validating-with-a-service-layer-cs

大应用程序：服务层现在是您的业务层的外观，其中验证发生在复杂的消息传递框架和工作流中。

我要指出，我喜欢在我的模型/视图模型上放置验证规则，无论应用程序的大小如何。我相信他们应该知道他们何时处于错误状态，这与违反业务规则时不同。

Answer 4

想法不是资源利用。但这个想法是曼斯菲尔德提到的关注点分离。

大多数人将模型误解为数据 - 原始数据。但这是不正确的。模型是数据的底层逻辑结构。这意味着针对当前上下文进行逻辑结构化和过滤的数据。因此，只有经过处理的数据应该来自您的模型。

由于这种关注点分离，您还可以对这三个部分进行独立的自动化测试。你可以完全独立于你的控制器来测试你的模型，反之亦然。