脂肪模型和皮包骨头的控制器听起来像创造上帝模型

我一直在阅读大量的博客，主张胖模型和瘦控制器的方法，尤其是。 Rails营地。因此，路由器基本上只是找出什么方法来调用什么控制器和所有的控制器方法就是调用模型上的相应方法，然后调出视图。所以我在这里有两个问题，我不明白：

控制器和路由器除了在基于路线的神似模型上调用一个方法之外，并没有做太多不同的任务。
模型做得太多了。发送电子邮件，创build关系，删除和修改其他模型，排队任务等。基本上现在你有上帝的对象，应该做任何可能或可能不涉及build模和处理数据的事情。

你在哪里画线？这不就是落入上帝的模式吗？

_{将Rails看作MVCdevise模式的主要元素可能不是最好的主意。} _{所说的框架是有一些固有的缺点（我在另一个post里有所阐述），社区才刚刚开始解决这个问题。} _{您可以将DataMapper2 开发视为第一步。}

一些理论

提出这个build议的人似乎受到一个相当普遍的误解的折磨。所以让我开始清理它： 模型，在现代的MVCdevise模式，不是一个类或对象。 模型是一个图层。

MVC模式背后的核心思想是关注点分离，第一步是表示层和模型层的划分。就像表示层分解成控制器（负责处理用户input的实例），视图（负责UI逻辑的实例）和模板/布局一样，模型层也是如此。

模型层的主要部分是：

域对象

也被称为域实体，业务对象或模型对象（我不喜欢后者的名称，因为它只是增加了混淆）。这些结构是人们通常错误地称之为“模型”的结构。他们负责包含业务规则（所有的math和特定单位的域逻辑validation）。
存储抽象：

通常使用数据映射器模式实现（不要与使用这个名字的ORM混淆）。这些实例通常负责信息的存储 – 从域和对象的检索。每个域对象可以有几个映射器，就像有几种forms的存储（数据库，caching，会话，cookie，/ dev / null）。
服务：

负责应用程序逻辑的结构（即域对象之间的交互以及域对象与存储抽象之间的交互）。它们应该像表示层通过其与模型层交互的“接口”一样。这通常是类似于Rails的代码在控制器中的结果。

这些组织之间也可能有几种结构： DAO ，工作单元和存储库。

_{哦…当我们谈论（在networking环境下）一个与MVC应用程序交互的用户时，它不是一个人。} _{“用户”实际上是您的networking浏览器。}

那么神呢？

控制器应该与服务交互，而不是使用一些可怕的单一模型。您将来自用户input的数据传递给特定的服务（例如MailService或RecognitionService ）。这样，控制器就会改变模型层的状态，但是这是通过使用一个清晰的API来完成的，并且不会干扰内部结构（这会导致抽象的漏洞）。

这样的改变可能会引起一些即时的反应，或者只影响视图实例从模型层请求的数据，或者两者兼而有之。

每个服务都可以与任何数量的域对象和存储抽象进行交互（但通常只有less数）。例如， RecogitionService可以不关心文章的存储抽象。

结束笔记

这样你就可以得到一个应用程序，可以在任何级别进行unit testing，耦合度低（如果正确实施），并有明确的架构。

虽然，请记住：MVC不适用于小型应用程序。如果您正在使用MVC模式编写留言页面，那么您就错了。这种模式是为了执行大规模应用程序的法律和秩序 。

_{对于使用PHP作为主要语言的人来说，这个post可能是相关的。} _{用一些代码片段对模型图层进行更长的描述。}

如果“模范”课程实施得不好是的，你的关注是相关的。模型类不应该做电子邮件（基础设施任务）。

真正的问题是MVC中的模型意味着什么。它不限于POCO类与几个方法。 MVC中的模型意味着数据和业务逻辑。将其视为经典核心POCO模型的超集。

查看====控制器====模型—>业务stream程层 – >核心模型

抛出基础设施程序集和数据访问层，并使用注入把它交给BPL，那么你的一个进程正在按照预期使用MVC。

BPL可以调用UoW / Respository模式，并通过注入对象或接口模式执行业务规则和调用基础结构特性。

因此，保持控制器瘦身的build议并不意味着传统Core模型中的“人”类应该有50个方法，并直接调用电子邮件。你是对的，认为这是错的。

如果直接调用，控制器可能仍然需要实例化并注入基础结构类到BPL或核心层。应该有一个业务层或者至less是在Classic Object模型类中编排调用的类。那么这是我的“观点”无论如何;-)

对于通用的MVC wiki的描述http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller

在MVC中谈论“M”的小博客。 http://www.thedeveloperday.com/skinny-controllers/

我认为你可以区分单一的胖模型（可能命名为应用程序或应用程序）和几个胖模型分为逻辑组（业务，客户，订单，消息）。后者是我如何构build我的应用程序，每个模型大致对应于关系数据库中的数据库表或文档数据库中的集合。这些模型处理创build，更新和操纵组成模型的数据的所有方面，无论是与数据库交谈还是调用API。该控制器非常薄，负责调用适当的模型和select模板的小mor。