其实这几天一直都想找时间把这个感悟整理出来，也是这一段一直思考的问题，因为这一段参加一个PHP后台项目的开发，框架使用的是CI，随着项目的进展，对于CI接触的也越多，但是由于理解的可能并不深刻，我也只是看到了我所看到的，所以如果有不对的地方，欢迎给出意见和指正。
这几天接触CI框架，发现它的MVC模式运用的如此清晰简洁，完全按照MVC的分别组织模块，而且Model、View与Controller的交互只要调用方法就可以，如果有大量交互，Controller里的方法数量或许会增多，但也可以分模块的剥离来简化Controller，不过，这种方法数量的增多并不会造成Controller的臃肿，因为用户和界面相关的交互都在view中用JS动态完成，而Model的修改，controller也就是调用Model传参，View在向controller的主动交互中好像并没有受到限制，而目前我知道Model可以返回数据给Controller，但还不知道怎么主动调用Controller。不过这种单一流程的简洁性起初就已经让我惊讶了一把。虽然MVC模式的含义在哪里都是一样的，但运用的不同和语言架构的不同却会导致不同的结果和影响，比如iOS中MVC的交互里就限制了View和Model主动向controller的交互，并不是不能，只是做了一层限制，controller可以*调用View和Model，传参最简单的方式就是属性传值，而如果一个View有了用户操作后想要调用controller就不会那么容易了，不过代理可以解除这个问题，只是代理委托模式再清晰，最后交互的主体操作都是在controller里；而Model如果又发生改变又想要congtroller做出回应，就更不容易了，KVO模式和通知的使用也可以解决，但这一层限制是避免不掉的。
从CI来看，View层并不只是显示，用户交互操作留在View里或许可以让controller不至于那么臃肿，而MVC下Controller的臃肿却是iOS架构模式中一直在讨论的问题，但是如果把一部分用户操作的响应直接放在View层也会有问题，很多时候View层可以接收用户操作，但如果不和Model沟通是无法响应的，还是避免不掉通过controller，那么到底应该从哪里入手呢，我最后的想法是，应该是Model，也许Model并不是只能作为一个数据内容的展示，如果给它必要的方法，也许可以帮助Controller分担一部分的工作，但这毕竟是有限的。
其实我以前也一直认为iOS里如果将controller的内容进行模块划分，是可以降低controller的冗余的，如果现在再给Model分担一部分内容，冗余程度会更低一些，但是终究是无法达到CI的这样简洁，而因为对controller冗余问题的讨论也诞生了MVVM，只是我对这种模式的运用并不能很熟练，只是知道大概是怎么个情况，而且目前的MVVM模式也不像MVC那么的成熟，精简controller估计会是要一直进行的一个讨论了。