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

Question

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

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

控制器应该启动数据访问代码吗？认为按钮点击，重新加载订单查询。还是应该通过模型层？

任何示例代码都会很棒！

Answer 1

通常我实现的MVC如下：

查看 - 从控制器接收数据并生成输出。通常只有显示逻辑应该出现在这里。例如，如果您想采用现有网站并生成移动版/ iPhone版本，则只需更换视图即可（假定您需要相同的功能）。

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

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

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

如果您遵循此方法，模型最终会变得非常通用且可重用。您的控制器的大小和复杂程度都是可控的，因为数据访问和显示已分别被移除到模型和视图中，您的视图应该足够简单，以便设计师（只需少量培训）就能理解它们。

Answer 2

该视图会将UI中发生的单击事件转发给控制层，该控制层将包含所有业务逻辑，并将依次调用仅进行数据库调用的模型层。只有模型层应该进行数据库调用，否则你将打败MVC设计模式的目的。

想想这样。假设你改变你的数据库。您需要限制所需的代码更改量，并将所有这些更改保留在一起，而不会影响其他应用程序。因此，通过保留模型图层中的所有数据访问，即使是简单的调用，您也可以限制模型图层所需的任何更改。如果出于任何原因绕过模型图层，则现在必须将知道数据库的任何代码所需的任何更改延长，从而使此类维护比应该更复杂。

Answer 3

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

控制器被实例化为具有服务接口的构造函数，例如， ISomeService作为参数。控制器本身不知道如何实现服务层，但他们可以访问它们。然后我可以轻松地替换SqlSomeService或InMemorySomeService。例如：ICatalogRepository与SqlServerCatalogRepositry：ICatalogRepository交给了CatalogService（ICatalogRepository，ISomeOtherDependency），这个实现将一个域（模型）图层库作为参数传递给它的构造函数。 。

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

Answer 4

我不会把数据访问代码放在控制器中。

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

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