在MVC中，Controller有哪些限制？

Question

Controller应该对Model对象进行直接赋值，还是告诉Model需要做什么？

Answer 1

控制器有两个传统角色：

1. 从UI处理输入事件（已注册的处理程序或回调）

2. 通知模型一个动作 - 可能会也可能不会导致模型状态发生变化

它不会执行模型上的数据验证，也不会对信息的呈现方式有任何发言权。

Answer 2

这在很大程度上取决于您的申请范围。如果它相对快速和肮脏，则过度工程没有任何意义，当然，您的控制器可以与您的模型对象进行对话。另一方面，如果出于某种原因需要更“企业化”，与MVC结合使用的良好模式就是所谓的“业务代表”。在这里，您可以在一个或多个模型对象上使用一个或多个方法组合粗粒度方法;例如，删除一个对象，然后返回一个没有该对象的刷新列表。该层有两个优点。首先，它将控制器与用于模型对象的任何ORM系统分离。此外，它最终必须建设性地处理可能发生的任何异常，而不是重新抛出它们。

Answer 3

我认为控制器不应该处理模型对象。

我倾向于认为控制器实际上是UI层的一部分。我更喜欢在控制器和应用程序的其余部分之间注入服务层。 Web层接受HTTP请求，将请求对象中的参数解组为服务接口可以处理的对象，并将响应编组回发送。所有与事务，工作单元以及处理模型和持久性对象的工作都由服务完成。

这种方法更注重服务。它将服务与用户界面分开，从而使多个客户端可以重用相同的服务。它使得对服务的请求编组的层“瘦”，因此很容易为REST或EJB或CORBA或者下一个新的东西切换出SOAP服务。

Answer 4

模型服务不必知道控制器的存在，因此，控制器可以通过利用模型服务来完成视图所需的内容。