MVC：关于数据访问的视图和模型交互等

Question

模型应该只是数据结构吗？服务（数据访问，业务逻辑）在MVC中的位置在哪里？

让我们假设我有一个显示客户订单列表的视图。我有一个控制器类来处理视图控件（按钮等）上的点击。

控制器应该启动数据访问代码吗？单击Think按钮，重新加载订单查询。或者这应该通过模型层？

任何示例代码都会很棒！

Answer 1

通常我按如下方式实现MVC：

视图 - 从控制器接收数据并生成输出。通常，此处仅显示逻辑逻辑。例如，如果您想要一个现有的网站并生成它的移动/ iPhone版本，您应该能够通过替换视图来做到这一点（假设您想要相同的功能）。

模型 - 包裹对模型中数据的访问。在我的应用程序中，所有SQL都存在于模型层中，视图或控制器中不允许直接访问数据。正如Elie在另一个答案中指出的那样，这里的想法是（至少部分地）将控制器/视图与数据库结构的变化隔离开来。模型也是实现逻辑的好地方，例如每当字段更改时更新“上次修改”日期。如果应用程序的主要数据源是外部Web服务，请考虑是否将其包装在模型类中。

控制器 - 用于将模型和视图粘合在一起。在此处实现应用程序逻辑，验证表单，将数据从模型传输到视图等等。

例如，在我的应用程序中，当请求页面时，控制器将从模型中获取所需的任何数据，并将其传递给视图以生成用户看到的页面。如果该页面是表单，则可以提交表单，控制器处理验证，创建必要的模型并使用它来保存数据。

如果您遵循此方法，模型最终会非常通用且可重复使用。您的控制器具有可管理的大小和复杂性，因为数据访问和显示已分别移除到模型和视图，并且您的视图应该足够简单，以便设计人员（通过一点培训）可以理解它们。

Answer 2

我不会将数据访问代码放在Controller中。

基于已经说过的内容，考虑在图层中分层是很重要的。例如，您可能在模型本身中有多个层 - 一个执行任何ORM和数据库访问的数据访问层和一个代表Business Objects的更抽象层（不知道如何访问其数据）。

这将允许您更轻松地测试系统的组件，因为它支持模拟。

Answer 3

我喜欢在域（模型）层中保留模型持久性或服务访问的“契约”或接口。我将数据访问或服务调用的实现放在另一层。

控制器用构造函数实例化，这些构造函数接受服务的接口，例如： ISomeService，作为参数。控制器本身不知道如何实现服务层，但是他们可以访问它们。然后我可以轻松地替换SqlSomeService或InMemorySomeService。

我对一个具体的服务实现非常满意，该实现将域（模型）层存储库作为其构造函数的参数。例如：带有SqlServerCatalogRepositry的ICatalogRepository：ICatalogRepository传递给CatalogService（ICatalogRepository，ISomeOtherDependency）。

使用依赖注入框架，这种分离更容易。

Answer 4

View会将UI中的点击发生在控制层上，其中包含所有业务逻辑，然后调用只会进行数据库调用的Model层。只有模型层应该进行数据库调用，否则你将无法实现MVC设计模式的目的。

以这种方式思考。假设您更改了数据库。您可能希望限制所需的代码更改量，并将所有这些更改保持在一起，而不会影响应用程序的其他部分。因此，通过保持Model层中的所有数据访问，即使是简单的调用，您也可以限制Model层所需的任何更改。如果您出于任何原因绕过Model层，您现在必须扩展任何知道数据库的代码所需的任何更改，使这种维护比应该更复杂。