如今的Web开发，各种框架风起云涌，势如破竹。
从国民第一的ThinkPhp到称霸全球的Laravel，这些框架有一个共同特征，都采用了MVC的架构模式。
没有任何意外，王小二的公司用Thinkphp来开发公司的主打产品。
一天，小二刚到公司，正打算坐下来喝杯茶。
老大走了过来：“小二啊，现在有个新的需求。咱们之前提交订单的模块，需要增加发送邮件的功能，你看看能不能实现？”
小二想了想说：“没问题，最多3天搞定！”
看王小二胸有成竹的样子，老大满意的点了点头。
着手开干吧！小二打开熟悉的IDE，找到提交订单模块的Controller。
OMG!不看不知道，一看吓一跳，这个Controller的代码竟然接近2000行。
因为用户提交订单时，会与其他模块进行交互，需要的数据也比较复杂。只见此Controller，从Model层各种拿数据，然后各种逻辑处理，怪不得代码到了将近2000行。
“哎，这2000行代码，看着就头疼，可让我怎么写啊”…小二叹气道。
“要不再去请教下C哥？”
小二找到C哥，详细的描述了他的问题。
C哥喝了口水，淡定的说：“这个嘛，我之前也遇到过。”
“您也遇到过，怎么解决的？”
“这个问题，哈哈，姑且就叫MVC的烦恼吧！MVC将View与Model进行了分离解耦，这固然很好，但很多人就将业务逻辑的处理写在了Controller里，导致Controller越来越臃肿，以致最后都无法维护。”
“对对对，您说的太对了，我就经常这样写。”
[图：臃肿的代码]
C哥继续说道：其实，Controller不应该处理过多的业务逻辑。给你举两个例子就明白了。
1、控制器，就像遥控器一样。你见过遥控器关心电视怎么播放视频吗？没有，遥控器只是发送播放视频的信号，具体的播放视频的细节，遥控器不会关心。
2、控制器，就像将军一样。你见过将军亲自为每位士兵配备武器吗？细节部分，将军不必过问，将军的职责是领兵打仗，这叫各司其职，否则就乱了。
说到这里，小二恍然大悟：“听C哥一席话，胜读十年书啊！”
“既然这样，就给Controller减减肥吧。”
“是啊，但是怎么减肥呢？”
“我给你讲一种设计模式-外观模式，你就懂了”。
“好啊好啊，洗耳恭听”。
C哥又继续讲到：
外观模式，提供了统一的接口，用来访问子系统中的一群接口。外观模式定义了一个高层接口，使得子系统更加易用。
也就是说，干一件很复杂的事的时候，你想团队中每个人都花一年半载去学习如何做这件事吗？利用外观模式，我只需要指定一个人去学会这些复杂的步骤，然后我再告诉这个接口人去干就行了。
“如果让你实现上面那个需求，你可能会找到用户提交订单的Controller，然后在Controller里写下面的代码。是不是？”
“对对对，我会这么写”。
“其实你用的ThinkPhp，有一层叫Logic层，关于业务逻辑处理的部分，你可以写在Logic层里。这样，Controller层就变得很轻量了，好维护了。”
“你看，加了Logic层，业务逻辑都放在Logic里面去处理，Controller是不是瘦了很多呢？
Logic层为Controller提供了一个高层的接口用来发送邮件，也就是Facade模式的应用。”
“小二，明白些了吧？”“嗯嗯，明白了好多，犹如醍醐灌顶！”
“为了加深你的理解，我给你画个简单的实例图吧”。“真的吗？太谢谢C哥了”。
看了C哥画的图，小二又领会了一次，也算小彻小悟了。
“C哥,Facade模式真不错，你看，这样统一成简单的接口后，有很多好处呢：”
1、降低了系统的耦合度。提交订单的Controller，再也不用与UserController、EmailController等耦合了。现在只需要关心SendEmailFacadeLogic就可以了。
2、并且，用户使用了Facade模式后，有了统一的入口，就很容易监控客户对系统的使用了。就如Thinkphp的单一入口原则一样。
“嗯嗯。小二真聪明，确实是这样。”
更多精彩，请关注公众号“聊聊代码”，让我们一起聊聊“左手代码右手诗”的事儿。
