为什么 ASP.NET MVC 中的 MODEL 有时用作与此处的数据库通信的应用程序的一部分，有时用作跨应用程序传递数据的业务对象，例如此处？
问问题
834 次
6 回答
4
正如您所发现的，自从 Smalltalk 开始以来，MVC 已经朝着不同的方向发展，它经常被用来描述非常不同的架构。
Martin Fowler 在这里写了关于 MVC 演变的博客。http://martinfowler.com/eaaDev/uiArchs.html
这里有对 MVC、MVP 和 MVVM 之间差异的解释：http: //joel.inpointform.net/software-development/mvvm-vs-mvp-vs-mvc-the-differences-explained/
我的10c：
ASP.NET MVC 3 的许多示例比 MVC 更接近于 MVVM 模式。在 MVVM 中，ViewModels 是为每个 View 的数据细节量身定制的（即，“ViewModels”不仅仅是域模型，而是装饰有 View/Presentation Tier 关注点，例如验证规则、字段提示/名称、字段可见性等）。
（回到 MVC）在不需要太多后端分层的较小的以数据为中心的项目中，M 可以像 ORM 模型（例如，带有一些自动生成的 POCO 的 .EDMX）一样简单，具有一些规则。在这种情况下，MVC 几乎可以被视为一种应用程序架构。
但是在使用 MVC 的大型项目中，模型的原始（Smalltalk）“M”现在被分成几个其他层，例如域实体、服务外观、服务（例如 SOA）、业务和数据层等（所以在这里， M VC是表示层模式，M 是系统的其余部分）。因此，例如在这样的项目中，您的 MVC 项目的“模型”文件夹可能只是代理服务引用和代理域实体，用于与系统的“后端”通信，甚至是这种通信的抽象（例如，参见复合应用程序块中使用的服务代理/服务外观）。
于 2012-06-17T19:58:37.023 回答
3
因为这两件事都是 MVC 中的“模型”组件应该做的事情的一部分。
粗略地说，这三个组件的作用是：
- 模型实现了整个领域逻辑。这通常涉及持久性（例如数据库），但也涉及业务逻辑 - 在完美的 MVC 中，对域数据的任何修改都作为模型例程实现。
- 控制器从 UI（或任何面向公众的接口）读取输入，并将其分派到正确的模型例程。
- View将原始模型数据转换为 UI 可以呈现给公共界面的东西。
与多层架构不同，MVC 不区分域逻辑和数据持久性：模型实现了两者。
然而，实际上，大多数 MVC 实现并不是 100% 正确的。将模型简化为数据访问层是很常见的，大部分领域逻辑都发生在控制器中。事实上，有时不清楚输入验证（控制器的工作）在哪里结束，而实际的域处理（模型的工作）从哪里开始。关于数据如何从 Model 流向 View 也存在一些争议——Controller 是读回 Model 数据并将其传递给 View，还是 Model 主动将其结果传递给 View？或者视图应该是活动部分，向模型查询数据？
于 2012-06-17T20:03:52.903 回答
2
在模型视图控制器模式中，控制器处于领先地位。它确定渲染哪个视图以及传递给该视图的数据。
大多数时候，我们习惯于使用数据库来持久化模型的架构。但这不是一个要求。该模型还可以持久化到其他东西（例如 XML 或 Web 服务）。
M 也可以代表视图模型。这意味着您没有将实际模型从数据库传递到控制器以进行查看，而是您使用的是专门为视图量身定制的模型。
使用域驱动设计时，您的控制器仅用于调用域中的函数。域模型包含实际的业务逻辑并公开服务以访问您的持久性存储（存储库）并创建新对象（工厂）。控制器应尽可能平坦。
于 2012-06-17T20:04:37.097 回答
2
模型是 MVC 中最难理解的部分。
有些人从业务模型的角度来思考，所以他们会做一些事情，比如让他们的模型直接与数据库对话。
其他人则根据视图模型进行思考，因此他们最终得到了更简单的数据类。
就个人而言，我支持第二组，因为我认为它提供了更好的关注点分离。
于 2012-06-17T20:05:08.700 回答
1
第一张图片告诉您控制器从数据库构建模型，然后将模型传递给视图。第二个是相同的，但只包含一个简单的视图。
您可能需要检查：
于 2012-06-17T19:59:38.417 回答
1
我认为它是“业务逻辑”或“用户从网站获得的东西，而不是它的外观”。
于 2012-06-17T20:01:15.187 回答