以下内容因为涉及到多人，且有QQ号码在，故全部删除。
内容由三人构成
膘叔（我自己），枫YE（帅哥）、asers.Z（帅哥），以下是详细内容。。已经精简过了：
XML/HTML代码
- 说实话，刚才那个什么专家爱潜水说的。实在不敢苟同。
- 确实，从技术的角度讲，只要是程序员都会想着代码重用，纯粹OO，用上N种合适的设计模式。但是从业务角度上看，这些几乎是不可能实现的。
- 底层能够完美的实现OO啥的，已经很不容易了。而业务几乎天天在变，如果你用了纯OO，估计你会活活累死。
- 少量的OO还是应该使用的。但业务逻辑的复杂性才是设计的重头。
- 说白了。写代码确实没有一点技术含量。
- 你能写的功能，网络上基本上都全了。那。。为什么还要写呢？就因为一些业务逻辑与网上的不一样，客户的要求不一致。根本不能保证 这些不会变化。
- 在多变的世界里，如果追求速度，那当然是过程最快。如果要想着逻辑经常变化，那么也只有将部份内容封装，关键位置使用interface，业务基础采用abstract
- 其他的，我估计也没有什么埂 好的方法。
- 什么工厂模式，领域模型，真正有多少能够用在业务上？？往往都是用在底层。。。
- 唉。废话多了。不说了。
- 事实证明,基类是非常脆弱的
- 业务基类吧
- 底层基类应该是不会脆弱的。
- 不管是什么,往往小小的修改会给代码库造成很大的破坏
- 代码能够正常运行不代表没有问题
- 一个不合逻辑的方法被子类继承,然后被非法调用,这就是破坏
- 所以我在给我们公司的人讲的时候，和他们说底层代码用框架，而且是要尽量使用zendframework，为什么呢？
- 就因为几个原因
- 1、zend 是官方的，有官方社区在维护，不象国内或者网上的一些框架，都是靠个人在维护，真正有几个是社区型维护的？
- 2、正因为zend是官方的，一些ZEND自已没有开放的接口，可能从他们的代码里也可能会使用到，zend optimize应该也会做专门优化
- 3、文档。这是最重要的。。。有多少框架的文档象ZEND那样全？
- 4、兼容。。。兼容性也是很重要的一个环节，虽然ZEND不支持PHP4，但支持PHP5就足够了
- 5、也是我最放心的一点。代码的质量、手册、注释、更新、BUG的修复 。相对来讲都会比其他框架好一点，更重要的是。。。。。很多学PHP的人都会或多或少的学习一下zend框架，这样的话，在招人的时候也可以直接提一下会使用ZF，就行了。
- 有点重复，因为没有完全经过思考和重写
- OO也说不好的,OO的效率不高 但是管理方便啊
- 自己写一下也不错的.总用ZF有了依赖就不好了
- 用框架为什么呢、可能是因为可移植性高
- 框架最好少用
- 特定的系统框架不一定适用的
- 框架为了兼容很多系统所以都一一验证了，但在实际操作中，我们的程序都是跑在某一个系统下的。
- 这样，框架里面对其他系统的一些判断就成了无用代码，而且还占用了运算时间和其他。。。
- 这才是让我们最郁闷的。
- PATH_INFO，这个功能是被很多人拿来做dispatch的，可是。。。不是每个HTTP服务器都支持PATH_INFO
- 于是框架就会作上很多判断。。。而如果只在一个系统下面，我就可以直接写pathinfo并操作再判断。
- 节约了代码量和计算量。
- 是的
- 但，这种事情是说不准的。。。如果你换了一个CTO，你不能保证他会换服务器。。。
- 那就说不好了
- 是呀。这就是框架的作用了。。兼容性好。
- 更量的保证吧,像phpcms那样子写一套好一点
- 要知道，你做的不是商业程序。而且业务程序。。。
- 你判断那么多东西有意义不？？
- 如果你不敢保证以后会换服务器，你可以在调用前写个抽象类，实际使用的时候加载相应的类也是可以的。
- 这时候你就可以折腾你所谓的 工厂模式，单例模式、策略模式啥的了。
- 也可以套上个领域模型，啥的。。。
- 今天听我废话的人不多。。。。准备啤酒喝完就睡觉了。。
- 笔记本的电也快用完了。
- 哎
- 今天就是这么子在搞的
- 一个网站要拆开
- 拆成N个子站
- 结果一拆一堆乱呢
- 。。。。。。