php mvc框架中的控制器总感觉就是万能类.

在控制器中编写页面逻辑的时候，调度model逻辑的时候，因为一个控制器往往针对一个页面. 虽然控制器往往也是遵循class写法,但是感觉控制器写出来就是一个万能类.因为一个页面的功能数据多种多样,例如有商品数据,有用户数据等等. 可能都需要通过这个方法输出出来. 但是这就违背了 oop单一职责. 怎么解决这个问题呢?

回复内容：

在控制器中编写页面逻辑的时候，调度model逻辑的时候，因为一个控制器往往针对一个页面. 虽然控制器往往也是遵循class写法,但是感觉控制器写出来就是一个万能类.因为一个页面的功能数据多种多样,例如有商品数据,有用户数据等等. 可能都需要通过这个方法输出出来. 但是这就违背了 oop单一职责. 怎么解决这个问题呢?

这是个好问题。

程序都是根据业务逻辑而产生的。事实上如果你的页面要求多种数据汇集（注），那么你的程序就必然在某个单点出现多种数据的汇集。这是程序在业务逻辑约束之下产生的本征特点，用任何技术都是不可能消灭的。

在一个典型的MVC结构中，一般在C层汇集数据。所以一个C对接了一大堆的数据才是正常的。无需自创“超级类”这样凭空让我们感到担忧的名词。

立即学习“PHP免费学习笔记（深入）”；

实际上单一职责原则的重点在于“单一职责”，而不是“单一对接者”。对于Web框架的C，一般的职责只有：

1. 从M获取数据

2. 简单合并数据提供给V

3. 和HTTP等网络协议完成对接

所以“从多个M获取数据”这种情况，肯定是没有问题的。对接者多？只要对接做的事情是同一种，那就是单一责任。

但如果混入了任何以下的代码，那么C的单一职责就很可能出现了问题：

• 数据获取的具体方法，例如数据库读写（这是M的责任）

• 对获取的数据进行加工处理（这是M的责任）

• 将A模型获取来的数据传递给B模型（这是Service的责任）

• 组织并实现一个有若干个步骤的业务流程（这是Service的责任）

注1：例如商城的商品列表，一般有页眉的基本信息、页面正文的商品信息、侧边栏的商品类别信息，以及贯穿页面各处的广告推广信息等。

分层啊，加上一层，所有实质性操作都放在这一层，然后控制器调用

参考一下这个 是不是更有思路http://baike.baidu.com/link?url=DnVleYsISmUvUoyqcaupBzU7Zhk1mq3FPUM7ji55cp8xqBarGuSCI7vjdJk_vCj8rUYYqICUKt2SGKQ0GjJKRHExnXvydaHRn8tGQIKXPW7