关键字：oo 回到我前面提出的观点：“脱离了大量缓存和基于对象的业务逻辑的OO是没有意义的”。其道理是显而易见的，只有使用了大量缓存和基于对象的业务逻辑，建立一个OO结构的收益才远大于我们付出的代价，OO本身所在的“内存对象世界”也才具备了脱离“持久化对象世界”而存在的根本意义。如果我们能把大量适合放在内存中的业务逻辑搬移到应用内存中（而不是DB Server）的话，那效果就更好。当然也有一些操作不适合放在应用逻辑中，如针对特别大量数据的非个性化的成批更新操作。至于什么叫大量，这取决于性能的考虑和实证。将很多业务逻辑从数据库搬移到应用内存中是可行的，尤其是对于在执行前要根据很有限的数据条目进行大量判断来决定是否实质性产生某种数据改变的逻辑更是如此。代价是速度可能较存储过程差一点点，但是却避免了因为大量不符合规则从而根本不会产生实质数据改变的无效调用而导致的应用服务器到数据服务器的网络往复，二者相比，无谓的往复往往代价要高得多。对于现实的电子商务网站，这一点是非常有价值的。
2）OO并不是低性能的代名词，设计合理的OO会带来意想不到的高性能。
OO并不是低性能的代名词。恰恰相反，很多时候我都把OO当作我提升网站性能的基本武器：通过结构合理而算法高效的对象缓存技术以及与对象结合并在同一地址空间中执行的业务逻辑，我们往往能够轻易地提升系统的性能。当然，一切的前提在于正确的设计，这不断适用于OO，也适用于世间一切，没有什么东西脱离了其实现的细节而万岁千古！
以我们最近完成的一个较大型电子商务网站为例（目前日均订单〉12000，成交订单笔数在3000左右，而且最近增长势头很好），在运行近三个月后，该网站在Alexa的速度统计已经从早先的very slow（平均一个页面6~7妙），经过slow（Alexa的数据是累计的，所以不是立即跳变），上升到average（平均一个页面2.0s）。与此同时，DB Server的CPU Usage从原来的平均80%急剧的下降到平均10%！在现有系统中，基本上除了一些大批量数据移动和数据库服务器段数据分页查询之外，所有业务逻辑均存在于我们的应用逻辑中。这大概是违法很多朋友的开发直觉的。我经常听到的是：用存储过程吧，为了性能...我不是在一切场合都反对使用存储过程。但是我们必须清楚，每一种方法的优点是什么？缺点是什么？条件是什么？什么场合适用？什么场合不会适用，什么场合二者应该在更细微的场景/场合下分别或者混合使用。这有点象物理中的定理：谁见过没有适用条件的定理？
3）如果你关注Scale out的能力，你就更应该考虑OO。
现实世界的网站应用系统，都必须考虑Scalability问题，除非业务永不增长。只要业务会增长，使用人数不断增多，服务器就一定会很快达到性能和并发极限。解决这个问题，通常只有两个办法：Scale up——买更好的服务器，而这往往因其代价过于高昂而不现实；Scale out——买更多的服务器，这往往是最终的实际选择。但是Scale out始终面临着数据集中（就算是拆分过的数据仍然各自相对集中，能做到无限随意拆分吗）的问题。如果大量的逻辑放在数据库服务器一端，我相信很快数据库服务器就会使得系统失去Scale out的能力和可能。因此，要保证Scale out的能力就必须保证数据库（当然，必要的拆分策略也很重要，但那属于另一个话题）只处理实质性的数据提交和不可避免的数据查询，对于能够避免的数据查询和非实质性数据提交都应该想办法予以避免。这其实和我们上面所说的“脱离了大量缓存和基于对象的业务逻辑的OO是没有意义的”刚好结合起来，成为一举夺得的美事。
4）OO + N-Tier的基本思想乃至软件开发方法的所有其他动力是对逻辑聚合和复用地不断追求。
大家都知道，软件开发的分析设计方法一直在不端演化，新的概念不断涌现。软件开发也从最早的直线条的机器语言，到面向过程的汇编语言，再到面向对象的对象化分析设计及编程（继承、接口、多态），以及后来的DP（设计模式）、AOP(面向方面的编程)...。一系列的演化，确实让人有眼花缭乱之惑何从入手之惑。那么在这一演化过程中，一以贯之的是什么？始终不变的又是什么呢？
文章来源于领测软件测试网 https://www.ltesting.net/