网站WebSite应用特点是:看数据人多创建数据人少众所周知恰恰就是这点决定了缓存Cache对于网站WebSite系统重要性对于主要以静态内容为主小型简易网站WebSite我们在这里就没有讨论必要了真正有人气网站WebSite定是具有动态增长准静态内容(如新闻类网站WebSite内容不断增加但是本身很少修改)或者大量动态内容(如交易型电子商务网站WebSite)对于前种情况通常有两种方式来加速其访问种是生成静态页面种是在内存中缓存Cache页面内容生成静态页面在性能上未必总是最好选择只有当数据多到内存中根本缓存Cache不下而这些数据又都有很大可能被用户访问时生成静态页面才是较佳选择在数据较多但是并发并不多时或者并发虽多但关注内容并不多时(如近两日新增信息或者近几日修改信息)页面缓存Cache就是更好选择原因很简单页面缓存Cache访问速度要明显快于静态页面当然有时候 2者可以结合起来这里就不多讲了对于后种情况——真正较大型电子商务性网站WebSite我们面对是另个问题:些信息被以网页形式缓存Cache但这些信息本身数据信息(如商品信息中剩余数量卖家Id等)常常需要被用到进行相关处理如果只是进行了网页缓存Cache而没有进行对象缓存Cache话缓存Cache意义就不打在这种情况下对象缓存Cache就成为最好选择其实在前种情况下页面缓存Cache也可以以对象缓存Cache形式单独或者分级混合并存

回到我前面提出观点:“脱离了大量缓存Cache和基于对象业务逻辑OO是没有意义”其道理是显而易见只有使用了大量缓存Cache和基于对象业务逻辑建立个OO结构收益才远大于我们付出代价OO本身所在“内存对象世界”也才具备了脱离“持久化对象世界”而存在根本意义如果我们能把大量适合放在内存中业务逻辑搬移到应用内存中(而不是DB Server)话那效果就更好当然也有些操作不适合放在应用逻辑中如针对特别大量数据非个性化成批更新操作至于什么叫大量这取决于性能考虑和实证将很多业务逻辑从数据库搬移到应用内存中是可行尤其是对于在执行前要根据很有限数据条目进行大量判断来决定是否实质性产生某种数据改变逻辑更是如此代价是速度可能较存储过程差点点但是却避免了大量不符合规则从而根本不会产生实质数据改变无效而导致应用服务器到数据服务器网络往复 2者相比无谓往复往往代价要高得多对于现实电子商务网站WebSite这点是非常有价值

2)OO并不是低性能代名词设计合理OO会带来意想不到高性能

OO并不是低性能代名词恰恰相反很多时候我都把OO当作我提升网站WebSite性能基本武器:通过结构合理而算法高效对象缓存Cache技术以及和对象结合并在同地址空间中执行业务逻辑我们往往能够轻易地提升系统性能当然切前提在于正确设计这不断适用于OO也适用于世间切没有什么东西脱离了其实现细节而万岁千古！

以我们最近完成个较大型电子商务网站WebSite为例(目前日均订单〉12000成交订单笔数在3000左右而且最近增长势头很好)在运行近 3个月后该网站WebSite在Alexa速度统计已经从早先very slow(平均个页面6~7妙)经过slow(Alexa数据是累计所以不是立即跳变)上升到average(平均个页面2.0s)和此同时DB ServerCPU Usage从原来平均80%急剧下降到平均10%！在现有系统中基本上除了些大批量数据移动和数据库服务器段数据分页查询的外所有业务逻辑均存在于我们应用逻辑中这大概是违法很多朋友开发直觉我经常听到是:用存储过程吧为了性能...我不是在切场合都反对使用存储过程但是我们必须清楚每种思路方法优点是什么？缺点是什么？条件是什么？什么场合适用？什么场合不会适用什么场合 2者应该在更细微场景/场合下分别或者混合使用这有点象物理中定理:谁见过没有适用条件定理？[Page]

3)如果你关注Scale out能力你就更应该考虑OO

现实世界网站WebSite应用系统都必须考虑Scalability问题除非业务永不增长只要业务会增长使用人数不断增多服务器就定会很快达到性能和并发极限解决这个问题通常只有两个办法:Scale up——买更好服务器而这往往因其代价过于高昂而不现实；Scale out——买更多服务器这往往是最终实际选择但是Scale out始终面临着数据集中(就算是拆分过数据仍然各自相对集中能做到无限随意拆分吗)问题如果大量逻辑放在数据库服务器端我相信很快数据库服务器就会使得系统失去Scale out能力和可能因此要保证Scale out能力就必须保证数据库(当然必要拆分策略也很重要但那属于另个话题)只处理实质性数据提交和不可避免数据查询对于能够避免数据查询和非实质性数据提交都应该想办法予以避免这其实和我们上面所说“脱离了大量缓存Cache和基于对象业务逻辑OO是没有意义”刚好结合起来成为举夺得美事

4)OO + N-Tier基本思想乃至软件Software开发思路方法所有其他动力是对逻辑聚合和复用地不断追求

大家都知道软件Software开发分析设计思路方法直在不端演化新概念不断涌现软件Software开发也从最早直线条机器语言到面向过程汇编语言再到面向对象对象化分析设计及编程(继承、接口、多态)以及后来DP(设计模式)、AOP(面向方面编程)...系列演化确实让人有眼花缭乱的惑何从入手的惑那么在这演化过程中以贯的是什么？始终不变又是什么呢？ 在回答这个问题前我们先来看看MVCMVC是现在大家都很熟悉设计模式那么到底什么是MVC呢？下面是Wikipedia有关MVC解释:Model-View-Controller (MVC) is a software architecture that separates an application\'s data model, user erface, and control logic o three distinct components so that modications to the view component can be made with minimal impact to the data model component. 翻译过来就是:MVC是种将应用数据模型、用户界面(视图)以及控制逻辑分解到区别组件中软件Software构架这种分解可以使得视图组件细修改对数据模型只会产生很小影响或者根本不产生影响



在研究问题时候我喜欢跳出问题来看问题在跨越时间甚至跨越领域大跨度类比中不断完成思想升级及重构回到前面问题在软件Software开发分析设计思路方法上以贯的其实就是种类似于MVC思想:对问题域不断进行重构使得种数据(不要狭隘看待数据信息、规则、动作切都可以被看作是数据)、该数据管控逻辑、以及该数据使用者( 不定是UIUI只是特例)能够被区分开来从这个角度来看待软件Software开发领域切你就会发现切都在改变切也都没有改变我们只是为我们以贯的思路方法找到了应用发领域如此而已再简化点实质上切软件Software设计思路方法突破都是在于指明新逻辑聚合方向,建立了新逻辑聚合思路方法OO如此AOP如此设计模式如此切都是如此[Page]

5)只有些很特定情况不适用OO + N-Tier

当然不是所有场合都必须或者适用OO + Np-Tier 2者引入无疑会在某些方面增加成本因此我们必须考虑我们付出时候会得到什么我们得到时候又会失去什么？权衡——这实际上也是我们做切事情最基本思路而不只是针对软件Software开发

大家可以自己权衡何时使用OO + N-Tier下面是我认为不适合些场合:

a)太简单应用写起来没几句代码使用OO + N-Tier根本不值得

b)已经有套很接近目标系统原型系统暂时没有必要使用OO + N-Tier成本不合算

c)开发人员完全不知道该如何使用OO + N-Tier教育成本不低暂时不建议使用

d)实时、密集信息处理其处理过程非常简单连判断都很少使用OO + N-Tier根本没必要