脂肪模型和瘦小的控制器听起来像创造神模型

Question

我一直在阅读很多博客,主张胖模型和瘦控制器方法,尤其是.Rails阵营.因此,路由器基本上只是找出在什么控制器上调用什么方法,并且所有控制器方法都在调用模型上的相应方法然后调出视图.所以我在这里有两个我不明白的问题:

你在哪里划线？这不仅仅是落入神模式吗？

Answer 1

_{将Rails视为MVC设计模式的主要内容可能不是最好的主意.所述框架具有一些固有的缺点(我在另一篇文章中对其进行了详细阐述),而刚刚开始解决后果的社区.您可以将DataMapper2 开发视为第一个主要步骤.}

提供这种建议的人似乎受到一种非常普遍的误解的折磨.因此,让我从清理开始:模型,在现代MVC设计模式中,不是类或对象.模型是一个层.

MVC模式背后的核心思想是Separation of Concerns,其中的第一步是表示层和模型层之间的划分.就像表示层分解为控制器(实例,负责处理用户输入),视图(实例,负责UI逻辑)和模板/布局一样,模型层也是如此.

模型层包含的主要部分是:

域对象

也称为域实体,业务对象或模型对象(我不喜欢后一个名称,因为它只会增加混淆).这些结构是人们通常错误地称之为"模型"的结构.他们负责包含业务规则(针对特定域逻辑单元的所有数学和验证).
存储抽象:

通常使用数据映射器模式实现(不要与滥用此名称的ORM混淆).这些实例通常的任务是从域对象中存储信息并将其检索到域对象中.每个域对象可以有几个映射器,就像有几种形式的存储(DB,缓存,会话,cookie,/ dev/null).
服务:

负责应用程序逻辑的结构(即域对象之间的交互以及域对象和存储抽象之间的交互).它们应该像表示层与模型层交互的"接口".这通常是Rails类代码最终出现在控制器中的内容.

在这些组之间的空间中也可能存在多种结构:DAO,工作单元和存储库.

_{哦......当我们谈论(在网络环境中)关于与MVC应用程序交互的用户时,它不是一个人."用户"实际上是您的网络浏览器.}

控制器应与服务进行交互,而不是使用一些可怕的单片模型.您将数据从用户输入传递到特定服务(例如MailService或RecognitionService).这样控制器就会改变模型层的状态,但是它是通过使用一个清晰的API完成的,而不会弄乱内部结构(这会导致漏洞抽象).

此类更改可能会导致某些立即反应,或者仅影响视图实例从模型层请求的数据,或两者都有.

每个服务都可以与域对象和存储抽象的任何数字(尽管通常只有少数)进行交互.例如,RecogitionService对于文章的存储抽象不太关心.

通过这种方式,您可以获得可在任何级别进行单元测试的应用程序,具有低耦合(如果正确实现)并且具有清晰易懂的架构.

但是,请记住:MVC不适用于小型应用程序.如果您正在使用MVC模式编写留言板页面,那么您做错了.此模式旨在强制执行大规模应用程序的法律和秩序.

_{对于使用PHP作为主要语言的人来说,这篇文章可能是相关的.使用一些代码片段对模型层进行更长时间的描述.}

@johnny据我所知.大多数php的所谓"mvc框架"都是Rails的变种.而且,作为课程的一部分,他们中的大多数都带有一些[活动记录](http://www.martinfowler.com/eaaCatalog/activeRecord.html)的ORM解决方案(这些东西对于数据库更改而言非常脆弱).您可以使用SF2.x或ZF2.x实现类似的功能,但框架的目的不是实现/实施特定的体系结构,而是提供工具.此外,当谈到MVC时,它是由**应用程序代码**而不是框架实现的. (3认同)
@thermz，*afaik*，确实没有专门处理 MVC 模式的书籍。我通常只是告诉人们阅读[**PoEAA**](http://www.amazon.com/dp/0321127420)，然后去挖掘。也许这个 [**链接列表**](http://stackoverflow.com/a/16356866/727208) 可能有用。我发现，当人们对 OOP 的原理和概念有了扎实的把握时，模式就变得很容易理解了。 (2认同)

Answer 2

如果"模型"类的实施效果不佳,那么您的关注点是相关的.模型类不应该做电子邮件(基础结构任务).

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

查看====控制器====模型--->业务流程层 - >核心模型

抛出基础架构组件和数据访问层,并使用注入将其传递到BPL,然后您的进程正在按预期使用MVC.

BPL可以调用UoW/Respository模式,执行业务规则并通过注入的对象或接口模式调用基础结构功能.

因此,保持控制器瘦的建议并不意味着经典Core模型中的"person"类应该有50种方法,并直接调用Email.你认为这是错的是对的.

如果直接调用,Controller可能仍然需要实例化并将Infrastructure类注入BPL或核心层.应该有一个业务层或至少是经典对象模型类中编排调用的类.好吧那就是我的"观点"无论如何;-)