结合codeigniter来讨论下mvc的缺点
本帖最后由 xiaoniao 于 2009-9-24 18:49 编辑原文：http://www.phpall.cn/forum/read.php?tid=188
mvc大行其道，它的优点大家应该听了很多了。
我这里来简单说下mvc的缺点。
第一：增加了系统结构的复杂性。
以前大家用面向过程的php写程序，需要显示数据的时候，用一个成语来说吧，直来直往。先连接数据库，再取数据，然后循环操作数据。有些人可能觉得这个过程下来三五句代码就可以搞定。但是当你用了mvc的codeigniter框架来写的时候会发现取数据在model层，数据摆好以后，然后再把数据交给controller层，最后视图层才能调用。经过了几个来回才得到你的数据。
严格遵守“模型-视图-控制”分离的结构并不总是创建交互式应用程序的最佳方法。对于简单的人机交互界面，如仅有菜单或者简单文档的系统，若采用分离的模型，视图和控制器组件就增加了系统的复杂性，降低了效率。
第二视图与控制器间的连接过于紧密
视图与控制器是分离，又是紧密相连的组件。这种关系就妨碍了单个组件的可重用性。想想看在codeigniter中写的视图层，大多是针对controller层来写。如果如果换了controller，你写的那个视图还可以很方便的重复利用吗？有的人说可以。当然你又得去改写匹配新的控制器的视图了。因为除了那些只读的视图（即不参与数据交互的那些视图），视图离开控制器，它的使用就很有限。
第三。数据访问的低效率
这里我想大家很容易想像出来，还是结合codeigniter，我们现在写好了一个view，现在这个view需要再调用其他新的数据。这时它又必须依赖与model层的操作接口，再转向controller这样多次调用才能得到你想要的数据。试想如果系统的更新非常频繁，对于一些为改变数据的不必要的重复请求，将恶化系统的功能。这里提高一个改进的方法，就是在视图层设置数据缓冲。 不赞成你的观点，完毕。 第一：增加了系统结构的复杂性。
首先，你得看你做什么项目了，如果只是写个留言本之类的，用框架当然是适得其反，增加结构的复杂性，但是如果做一个大型的购物网站或者其他大型应用，如果不用MVC合理地管理代码，维护成本是相当高的，之前我的做大一点儿的项目，我基本上懒得再去看，都不知道该从哪里翻起，更别说扩展、修改、升级等。本身MVC概念的产生就是为了使复杂的问题简单化，就是为了去简化项目管理的，就是针对复杂的东西的。
第二：视图与控制器间的连接过于紧密。
你有什么好的办法去解决视图和PHP代码的“紧耦合”吗？复杂的应用不可能像有的开源BLOG那样方便地替换“皮肤”，打个比方，一个显示商家信息（认证信息、货物信息、出售信息、评价信息、物流信息等等）的页面，即使做一个HTML也是很麻烦的。。。呵呵，讨论这个问题有点像讨论“生活太复杂”这个概念。
第三。数据访问的低效率
这个问题我相对认可，但是用框架开发效率很高，你不这样认为吗？而且合理的程序逻辑、合理的数据库结构、合理的页面缓存等完全可以在最大限度上提升性能。 呵呵 欢迎大家批评指正。 和我刚开始接触mvc时候一样的观点，现在想想那时很傻很天真 MVC的一个特点是不好在dw中所见即所得。
但也不是没有解决办法 其实 CI 并不是非常严格的 MVC，所以给开发者留得余地很大，CI 的目标就是让开发者按照自己的方式来编程。 mvc只是其中一种软件的体系结构，还有很多其他的结构的。我这里主要目的不是说codeigniter框架，是说mvc。 LZ说的不无道理我觉得，不过大家跟帖也说的很对啊~总之就是随机应变~~ mvc只是其中一种软件的体系结构，还有很多其他的结构的。我这里主要目的不是说codeigniter框架，是说mvc。
xiaoniao 发表于 2009-9-25 10:58 http://codeigniter.org.cn/forums/images/common/back.gif
呵呵，所以说，用 CI 可以最大限度发挥 MVC 的优势，避免 MVC 的劣势，哈哈
页:
[1]
2