Why OO+多层结构? 来自实战的深入思考...（请求置顶）
面向对象的话题本来是个老话题了。只是看到还有不少人对这个问题有所困惑，我也就不吝浅薄，谈谈自己对面向对象的理解。还请大家在读过之后，能够不计鄙人的浅薄，多提宝贵意见。不断地争论和讨论是前进的根本动力。
（更多精彩，请访问我的博客：http://blog.csdn.net/aafshzj/）
面向对象的整套方法本来可以分为面向对象分析、面向对象设计、面向对象编程等。但是在这点上，我是赞同XP的开发思想的：代码就是所有的设计。因此，我更愿意把面向对象看作一个整体：一切最终落实到体现了面向对象思想的代码。基于此种考虑，在这里我也不区分OOA/OOD/OOP，而是泛指在面向对象思想指导下的软件开发及实现全过程。需要注意的是：“体现了面向对象思想的代码”和“面向对象的代码”是不同的概念, C#,java的语言特点决定了无论有没有面向对象的灵魂，其编码的“肉体”都是面向对象的。
关于OO的应用场合，还有很多人在争论。前些天看到还有人说三层结构/多层结构不适用于网站开发。从根本上讲，这和OO是不是适用于网站开基本上是同一个问题。因为，很显然，OO和N-Tier常常是一件事情的两个不同方面，使用OO却不使用多层结构是难以想象的，使用N-Tier却不使用OO那我就更加不知其可了。总之，在我看来，这两件事情是紧密相连的。退一步讲，将二者紧密联系在一起，如果不是必然的话，至少也应被看作是开发过程中的一个Best Practice。
下面谈谈我对OO + N-Tier的几个基本观点：
1）脱离了大量缓存和基于对象的业务逻辑的OO是没有意义的。
我以前看到一些同道在进行OO开发的时候，对象常常只在数据加载和保存中的出现。对象更像是一个盒子，在需要数据时，我们建立数据库连接，获取结果集或者DataReader/ResultReader，将从数据库获得的数据“填充”到对象中，然后再将对象返回给上层应用使用；在需要保存数据时，过程基本是对称的：我们把对象中的数据，一个字段一个字段读出来，生成参数化的或者直接字符串拼接的查询语句，建立数据库连接，提交更新到数据库。如果OO的主要内容就是这些的话，OO如果不能说是完全没有意义的话，起码意义也不大。我们在付出了编写了大量对象代码并且在存储加载时多一道手续的代码和性能代价之后，得到的好处只是使上层应用操作数据的代码可读性更好并且能够进行一定的类型强制和检查。这常常是很多开发人员对OO很困惑的原因：OO看起来很美，但是做了那么多事情，难道就是为了看起来很美吗？这同时也成为一些编程老手把OO看作华而不实代名词的原因：美是美了一点，但是代码多了，性能差了，让书呆子们去用吧。之所以出现这种局面，其根本原因在于“内存对象世界”没有提供太多的附加值。
大家应该注意到“内存对象世界”这一说法。在我看来，对象至少有两个世界，一个是“持久化对象世界”，一个是“内存对象世界”，这是由当今计算机的结构特点决定的：如果数据要长期保存，数据就必须被保存到可持久化的媒介中；如果要进行运算，数据就必须被加载到可运算寻址的媒介中。前者就是DB Server等管理的硬盘、磁带机...，后者就是内存。在DB Server为中心的开发中，大家倾向于把所有逻辑直接放置在最接近“持久化对象世界”的DB Server中，并主要以存储过程的形式存在。但是这样就一定是最合理的吗？尤其是对于网站应用？如果这样确实是合理的话，OO还有什么意义呢？是不是OO真的如某些人所说，只适合于图形绘制等特定领域？要回答这些问题，我们还是要看看哪些情况下，“内存对象世界”能够相对独立于“持久化对象世界”发挥其作用，这样“内存对象世界”就具备了独立于“持久化对象世界”之外的独立意义。
网站应用的特点是：看数据的人多，创建数据的人少。众所周知，恰恰就是这一点决定了缓存对于网站系统的重要性。对于主要以静态内容为主的小型简易网站，我们在这里就没有讨论的必要了。真正有人气的网站一定是具有动态增长的准静态内容（如新闻类网站，内容不断增加，但是本身很少修改）或者大量动态内容（如交易型的电子商务网站）的。对于前一种情况，通常有两种方式来加速其访问，一种是生成静态页面，一种是在内存中缓存页面内容。生成静态页面在性能上未必总是最好的选择。只有当数据多到内存中根本缓存不下，而这些数据又都有很大可能被用户访问时，生成静态页面才是较佳选择。在数据较多，但是并发并不多时，或者并发虽多，但关注的内容并不多时（如近两日新增信息或者近几日修改信息），页面缓存就是更好的选择。原因很简单，因为页面缓存的访问速度要明显快于静态页面。当然，有时候二者可以结合起来，这里就不多讲了。对于后一种情况——真正的较大型电子商务性网站，我们面对的是另一个问题：一些信息被以网页形式缓存，但这些信息本身的数据信息（如商品信息中的剩余数量，卖家Id等）常常需要被用到进行相关处理，如果只是进行了网页缓存，而没有进行对象缓存的话，缓存的意义就不打。在这种情况下，对象缓存就成为最好的选择。其实，在前一种情况下，页面缓存也可以以对象缓存的形式单独或者分级混合并存。
回到我前面提出的观点：“脱离了大量缓存和基于对象的业务逻辑的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(面向方面的编程)...。一系列的演化，确实让人有眼花缭乱之惑何从入手之惑。那么在这一演化过程中，一以贯之的是什么？始终不变的又是什么呢？
...
问题点数：0、回复次数：76Top
1 楼aafshzj（生活需要breakthrough）回复于 2006-09-19 13:45:22 得分 0
写了这么多。大家如果觉得还可以看看，就请帮我顶！Top
2 楼jailu（jailu）回复于 2006-09-19 14:42:44 得分 0
帮顶一下，虽然很多内容还不大明白，不过确实有点同感Top
3 楼aafshzj（生活需要breakthrough）回复于 2006-09-19 15:13:38 得分 0
真是应者寥寥哦，大家关注的都是一些编程细节...Top
4 楼aafshzj（生活需要breakthrough）回复于 2006-09-19 21:30:17 得分 0
太息一声自己顶！Top
5 楼lanserzhao（）回复于 2006-09-20 15:13:15 得分 0
ASP.NET(c#,Ajax)技术讨论群30417196（限已工作人士）Top
6 楼eastsun_genius（大漠狂沙）回复于 2006-09-20 16:35:49 得分 0
说得很好，但话题太大太空，举个实例可能会更好！Top
7 楼aafshzj（生活需要breakthrough）回复于 2006-09-20 21:32:21 得分 0
ls朋友：
建议到我的博客（http://blog.csdn.net/aafshzj/）看看我的AAF系列。这篇文章只是一系列文章中间的休息之作，主要目的只是谈谈思路，对有一定实战经验的人可能会有一定启发。AAF系列基本上就是为了把这些“大而空”的思路具体化实心化的基础。
时机成熟之后，我还会推出基于AAF开发的应用源码。欢迎持续关注。Top
8 楼aafshzj（生活需要breakthrough）回复于 2006-09-22 15:10:48 得分 0
可惜了我的心血啊Top
9 楼rtdb（东临碣石）回复于 2006-09-23 23:05:35 得分 0
呵呵，支持一下。
》“脱离了大量缓存和基于对象的业务逻辑的OO是没有意义的”
楼主的做法是极正确的。说明在多层架构方面很有心得。
只是我建议改为：
“脱离了大量缓存和基于对象的业务逻辑的多层架构是没有意义的”。
这种说法更加直接些，因为OO的概念范围实在是太广了，
有很多时候与缓存及业务逻辑是没有关系的。
Top
10 楼jijl2001（jijl2001）回复于 2006-09-25 17:03:25 得分 0
楼主最好说说，分层和类的关系。
类＝属性 + 方法
在分层中怎么体现出来Top
11 楼Boterelax（）回复于 2006-09-27 15:28:39 得分 0
仔细阅过，顶一下，谢谢楼主分享。Top
12 楼yuwen16（rr）回复于 2006-09-28 08:56:45 得分 0
楼主，确实强，看过aaf的实战，虽然还不能编译运行，不过确实感觉到了大海的深度。
顶Top
13 楼hrh1979（剑仙）回复于 2006-09-28 11:43:20 得分 0
说的好，很有道理Top
14 楼lincai（隐身）回复于 2006-09-29 13:01:31 得分 0
讲一下大型网站的开发案例更好，谢谢了Top
15 楼aafshzj（生活需要breakthrough）回复于 2006-09-29 16:08:05 得分 0
谢谢楼上各位支持，大型网站的案例以后应该会有的。今天也更新了博客，欢迎大家光临。Top
16 楼aafshzj（生活需要breakthrough）回复于 2006-10-13 11:52:37 得分 0
起床咯Top
17 楼jiangchuandong（岁月的流逝......）回复于 2006-10-17 11:51:33 得分 0
谢谢楼主,让我理解了为什么要少用存储过程来实现业务逻辑;Top
18 楼aafshzj（生活需要breakthrough）回复于 2006-10-18 21:37:48 得分 0
其实，我也不是完全反对存储过程。在这方面，我的根本观点是：
1）尽可能丰富应用对象逻辑
2）基于实际情况决定是否使用存储过程，存储过程的ROI（考虑了频率和往复成本）比应用逻辑的ROI高不了多少时，优先考虑应用对象逻辑而不是存储过程。Top
19 楼edzhcom（http://edzh.com 技术文章，美女贴图）回复于 2006-10-19 15:23:29 得分 0
存储过程有什么坏处？
我的网站大量使用存储过程＋静态页＋缓存 和 OOTop
20 楼yggpc（）回复于 2006-10-24 18:33:53 得分 0
dingTop
21 楼fancystyle（鳞）回复于 2006-10-26 00:12:14 得分 0
mark
Top
22 楼aafshzj（生活需要breakthrough）回复于 2006-10-27 15:18:01 得分 0
...Top
23 楼Afritxia（能活不易）回复于 2006-10-29 21:35:51 得分 0
使用三层结构的确会影响执行速度！
但是，这些影响是微不足道的。
并且这和程序的可扩展性、可延展性比起来，更显得微不足道……
赞同楼主的大部分观点Top
24 楼yofly（阿飞）回复于 2006-10-30 11:02:15 得分 0
好
收藏Top
25 楼aafshzj（生活需要breakthrough）回复于 2006-10-30 13:54:13 得分 0
使用三层结构的确会影响执行速度！
但是，这些影响是微不足道的。
并且这和程序的可扩展性、可延展性比起来，更显得微不足道……
赞同楼主的大部分观点
=================================
一方面三层结构确实会在某些方面降低执行速度，别的不说，多了函数调用就会有影响，但是函数调用是在内存中执行的，除非存在有问题的代码或循环，其对速度影响几乎无法察觉。
另一方面，三层结构会使得缓存以及其它一些有助于提高速度/性能的方法变得较为容易。此消彼长，因此，如果设计得当，三层结构不单可以提高可扩展性、可延展性，有时候也可以提高性能。
当然，这里还是强调“有时候”，因为如果原来的代码确实已经做得非常好的话，甚至象某位同学所说也增加了“缓存”等机制的话，提升的空间就未必大了。但是除非设计和实现存在严重问题，三/多层结构一般也绝不会导致性能明显恶化。
实际上，大部分非三层结构的系统，设计往往未必达到无懈可击的地步。因此，通过设计良好的OO+多层结构+性能优化措施，系统的总体性能表现有所提高还是非常可能的。这也是上面说“有时候也可以提高性能”的“有时候”的主要意味。Top
26 楼mznumber1（浮躁）回复于 2006-11-06 22:55:30 得分 0
收起楼主的blog,慢慢看.有问题还望楼主解答/!谢谢!
帮顶!先.Top
27 楼TakeCare123（小心）回复于 2006-11-07 13:08:08 得分 0
MARKTop
28 楼ggggdiu（ggggdiu）回复于 2006-11-09 12:34:51 得分 0
正是我考虑的问题,我正想利用ADO.NET的DATASET对象,构造一个本地缓存通用框架,一直在努力平衡缓存数据的性能提升和内存消耗之间的关系.及缓存数据的消亡策略.
希望楼主多多指教Top
29 楼c1000（行者）回复于 2006-11-11 09:25:41 得分 0
写得很好，深有感触，只是在这方面还没有实践。Top
30 楼C5662601（你学的越多 你忘的越多 你学的越少 你忘的越少）回复于 2006-11-11 09:54:11 得分 0
只讲理论消化起来比较慢
在项目中成长的速度是最快的，我想大家都认可吧
如果LZ能从一个小的程序讲起就好了（越简单越好）
用OO思想分析设计编程 最好把这个小程序做成三层结构
这样对于我这样初学者会有很大帮助的
Top
31 楼wzg218（小舍）回复于 2006-11-18 16:17:41 得分 0
看了 不错的Top
32 楼ProjectDD（）回复于 2006-11-20 10:09:24 得分 0
听了C#设计模式的MSDN网络广播我对面向对象有了初步的了解，我个人的一些感受是，有和面向对象了实现面向对象切实的手段后，软件变得更加可“设计”了这一点很重要，另外软件因此而具有了这样一些重要的品质，开放性，应变力，健壮，等每一点都非常棒，只有开往的软件才可以不断的成长，具有应变力的软件才能够不断的完善，健壮的软件才能应对变化以提供最大可复用性。MSDN上的C#23种设计模式讲得很细，非常好，受益颇多，建议不妨听听看看。Top
33 楼jyk（今天由我来写的代码，明天就让程序自己完成！喜欢编程。和气生财。共同提高。共同进步！）回复于 2006-11-20 21:48:40 得分 0
看着眼熟Top
34 楼jyk（今天由我来写的代码，明天就让程序自己完成！喜欢编程。和气生财。共同提高。共同进步！）回复于 2006-11-20 21:50:16 得分 0
原来是一个人，呵呵，Top
35 楼aafshzj（生活需要breakthrough）回复于 2006-12-14 18:37:27 得分 0
自己顶一下。Top
36 楼I_Iverson（迷路的蚂蚁）回复于 2006-12-21 15:50:06 得分 0
怎么划分对象？实体类怎么实现是我比较大的迷惑，请赐教。Top
37 楼guoweihrh（guowei）回复于 2006-12-21 15:52:19 得分 0
支持，我在这方面一直都是比较模糊，学习，多多益善Top
38 楼bluedoctor（）回复于 2006-12-22 09:21:10 得分 0
说的有道理,帮忙顶下Top
39 楼jacobspring（）回复于 2006-12-25 09:49:22 得分 0
markTop
40 楼wuhuabucai（混乱）回复于 2006-12-29 11:08:11 得分 0
本人一知半解Top
41 楼gamix（枫）回复于 2006-12-30 14:51:38 得分 0
楼主我们的看法非常的相似啊！
不知道楼主看过Evans的《领域驱动设计》没有，这里说的很多概念其实在那本书中都有很好的解释。比如内存对象世界就是其中的Repositories概念。
我觉得有空可以交流交流。Top
42 楼realsnow（真雪无香/抵制日货（菜C＋＋鸟））回复于 2007-01-07 15:06:15 得分 0
楼主的一些想法，我觉得和我的想法不一致。“脱离了大量缓存和基于对象的业务逻辑的OO是没有意义的。”，这一句话的后一部分我是赞同的，但是前一半我觉得不对，缓存这个东西，说白了就是放在内存里面，提高访问速度的手段，其实和OO没有直接的关系，面向过程的编程方式也能够很容易的实现缓存。
楼主刚开始说了，觉得OO和好用。分析原因在于：现在用.net的人做ASP.net的人比较多，所以会产生OO不好用的想法，这个对OO思想的最大的误解不是.net导致的，可以说是.net目前在国内的应用领域范围导致的。在页面上面，OO的思想不能得到很好的体现，为什么？因为页面的逻辑相对于业务逻辑的后台系统来说，是相对简单的多的，在页面一级上可以说基本用不上或者是很少能够使用OO的设计（除了MVC模式）。
OO的核心是什么？是很容易的封装变化、更加低的耦合度、更加易于维护后后期的变化。这点在编写业务处理逻辑及其复杂的的企业级的时候，就可以非常好的发挥作用，OO可以提供灵活的架构，这个也是为什么要有设计模式和各种企业级系统模式的原因。
执行速度方面，单从运行来说，.net是慢的，这点不用否认，但是执行效率和开发者之间的直接联系，大家相信也都知道，这点没有什么好说的。而且.net做得东西，也不是要和别人比效率的，比的是能否更加好的满足需求。Top
43 楼jyk（今天由我来写的代码，明天就让程序自己完成！喜欢编程。和气生财。共同提高。共同进步！）回复于 2007-01-08 07:40:28 得分 0
http://blog.csdn.net/jyk/archive/2007/01/07/1476519.aspx
建议看看这个，我刚刚写的。程序架构方面的，也许是一个启发呢。Top
44 楼anzy（安子）回复于 2007-01-09 17:06:56 得分 0
写得好，顶一个～
目前国内大量的项目都是只有oo的肉
大量逻辑都是在存储过程中实现，事务也由存储过程控制
为什么呢？
因为面向过程的开发方法是最快速的，在客户紧张的项目时间表中，用面向过程的方法开发能最快的满足客户的需求，而客户是不会看你到底有没有oo或者是n-tier的
市场导向～～～Top
45 楼aafshzj（生活需要breakthrough）回复于 2007-01-16 16:29:55 得分 0
顶！ ^_^Top
46 楼kkun_3yue3（嘟啊嘟啊嘟啊嘟）回复于 2007-01-23 14:21:57 得分 0
必须标记一下！必须重读一遍！这是今天唯一有意义的事情Top
47 楼burnyxu（之浩）回复于 2007-01-26 21:25:44 得分 0
1）脱离了大量缓存和基于对象的业务逻辑的OO是没有意义的。
2）OO并不是低性能的代名词，设计合理的OO会带来意想不到的高性能。
3）如果你关注Scale out的能力，你就更应该考虑OO。
4）OO + N-Tier的基本思想乃至软件开发方法的所有其他动力是对逻辑聚合和复用地不断追求。
___________________________________________________________________________________
最近对ｏｏ很有兴趣，所以对本帖发表的看法，不一定正确。
以上四点大多是从程序的性能去评价ｏｏ，由此可以看出楼主对ｏｏ的理解不太到位，实现ｏｏ、模式是要以牺牲一些性能为代价的，那么为什么还要舍去那些方便且高效的ｉｆ，ｅｌｓｅ，ｓｗｉｔｃｈ，转而追求复杂而又难以理解ｓｔａｔｅ，ｆａｃｔｏｒｙ，ｔｅｍｐｌａｔｅ ｍｅｔｈｏｄ呢？
ｏｏ的提出与性能无关。无论是抽象，封装还是继承都是从解决软件内在复杂性角度出发的。对象模型的存在也不是简单为了数据的传递和缓存。其目的在于重用、解偶和提供可维护性更高的产品。至于分层的设计只是为了实现依赖性更小的模块而已。一个设计良好的ｏｏ系统的性能绝对比不上一个传统的面向过程的程序。但其高度的灵活性和抵御变化的能力使这点劣势显得无足轻重。所以要是从性能角度分析ｏｏ，确实有点舍本逐末了。
ＰＳ：最近连续读了《面向对象分析与设计》和《敏捷软件开发》发现自己对ｏｏ的理解有一种豁然开朗的感觉，再次也像有兴趣了解ｏｏ的朋友严重推荐以上著作。Top
48 楼aafshzj（生活需要breakthrough）回复于 2007-01-27 22:21:15 得分 0
burnyxu(之浩) 好像没有看我的文章。
“ｏｏ的提出与性能无关”。我没有说过oo的提出和性能有关吧？但是OO也罢AO也罢，if else也罢，最终都是用来编写应用，是应用就要或多或少要考虑性能问题。因此，基于OO的应用最终必将考虑性能问题，虽然这不是唯一要考虑的问题。很多人在稍微大点的系统中逃避应用OO，就是担心明显影响性能。因此，我在OO实战中讨论性能难道不是一个很有意义的话题？一切方法的价值最终在于实战，而不是对其自身“美妙”的迷恋、陶醉或者如希腊少年纳瑟斯般顾水自恋。
关于oo在为指令上的性能消耗，和因为更容易编写结构清晰的代码也更容易应用一些对象集的缓存和其它技术而带来的性能提升之间的关系，我已经在文章中说过了。非OO的代码，当然也能应用类似技术，但是现实中的一切都是有成本的，采用OO的方式来实现这些，个人认为成本较低。
“一个设计良好的ｏｏ系统的性能绝对比不上一个传统的面向过程的程序。”也许这句话需要加上一个限定：就是在不计成本不考虑问题自身特点的情况下。然而事实是，现实中的一切都需要考虑成本，现实中的一切问题都有自己的特点。Top
49 楼aafshzj（生活需要breakthrough）回复于 2007-01-27 22:23:44 得分 0
gamix(枫) ( ) ：你好！
没有看到你的留言。这本书我没有看过，不过我想观点有类似的地方一点都不奇怪。工程化的东西，类似的约束，类似的问题，最终往往很容易找到类似的答案。方法浑然一体，关键在于应用。
欢迎到我的blog交流。春节后，我可能更新较多。Top
50 楼aafshzj（生活需要breakthrough）回复于 2007-01-27 22:24:43 得分 0
也谢谢其它朋友的支持。Top
51 楼closetome（即鹿无虞，惟入于林中。君子几，不如舍。往吝。）回复于 2007-01-28 13:40:07 得分 0
面向对象分析与设计,应该拜读一下，楼主的思想很好，收藏了慢慢读Top
52 楼guyfe（.....）回复于 2007-01-28 22:13:08 得分 0
mark
Top
53 楼jjyjjyjjy（骑着蜗牛去旅行）回复于 2007-01-29 11:25:03 得分 0
顶楼主，确实比较有同感，光OO不谈性能确实没有什么意义。Top
54 楼linkerlin（连接者）回复于 2007-01-29 14:10:25 得分 0
同感！
DB 的存储过程适合用在少数边界情况。
普通应用的存储逻辑和业务逻辑最好放在应用服务器，这样比较好手动优化。
加大对于缓存的优化处理。
但是，ORM层怎么放呢？
Top
55 楼aafshzj（生活需要breakthrough）回复于 2007-02-01 13:00:42 得分 0
谢谢各位朋友！
linkerlin(连接者) ：
AAF的ORM是和应用逻辑一起部署的。可以通过编写时的Attribute设定和persistence.config文件两个层面设定，并存的情况下后者会覆盖前者。如果不作任何设定，会使用对象的类型名和属性/字段的名称作为数据库表名和字段名。
AAF另外还提供了一种配置文件动态覆盖技术，也就是说：可以在管理界面中编辑配置文件，这些配置信息可以在提交保存时，自动被复制到多台相关服务器。Top
56 楼wzhjs（Flower）回复于 2007-02-04 23:56:53 得分 0
我写的一个简单的 object cache
C#的
初试C# 2.0中的Generic : 实现简单的ObjectCache
http://wztonyhuang.spaces.live.com/blog/cns!4731EA544B1EDB71!220.entryTop
57 楼aafshzj（生活需要breakthrough）回复于 2007-02-07 18:19:21 得分 0
春节前最后一顶
Top
58 楼dragonforfly（飘零）回复于 2007-02-08 23:46:40 得分 0
不错，值得一看Top
59 楼sunnf（sunnf）回复于 2007-03-09 10:05:15 得分 0
好！！
Top
60 楼smartcreater（）回复于 2007-03-09 23:44:32 得分 0
"脱离了大量缓存和基于对象的业务逻辑的OO是没有意义的"?
是这样的吗？
OO的提出是因为软件规模的日益庞大，越来越复杂的基础上提出的，它的基本思想是更合理的用计算机语言来描述现实世界。
Cache与OO没有本质上的关系， Cache的出现无非是解决速度上的问题，而OO的目的不是加快响应速度，OO也不只是针对业务逻辑而诞生的。
.Net Framework中包含如此丰富的基础类库，从底层到UI，一应俱全OO设计；
它的OO没有"缓存"的概念，也没有"业务逻辑"的概念，难道它的这些都没有意义吗？
可以楼主的经历大多在网站层面！ 才出此言！！Top
61 楼jetxia（Thinking->Asking&Studying->Doing）回复于 2007-03-10 11:01:18 得分 0
看了 楼主和各位兄弟的回复
OO是何其博大，大家对OO基本上都是从一个角度看待整体，想想我们小时候学的盲人论象，大家所说的很有道理，站在某一点上来说也都是正确的，但是如果从OO反过来看待这些问题的话，在使用中有很多东西和OO是有一定的悖逆的。鉴于此，偶认为应该去接受更多的看待问题不同角度的分析结果，然后在实际应用中取其适用之处。
Top
62 楼spgoal（敏捷的狗狗）回复于 2007-03-12 09:49:51 得分 0
我觉得楼主的文章偏重于性能方面，个人认为，OO的出现的原因是为了减少需求变更所带来的返工成本，一个好的OO架构应该是低耦合高内聚的，具有高扩展性，而要达到这个目标，必须分层，是各个类的职责清晰，减少依赖性，但这样带来的结果就是性能的影响，所以我觉得性能与高扩展性是一对矛盾，而能缓解这个矛盾的手段之一就是楼主所说的建立完善的缓存机制Top
63 楼aafshzj（生活需要breakthrough）回复于 2007-03-12 18:29:24 得分 0
感谢各位的指教。smartcreater() 同学有点激动，呵呵，不过没关系。
其实smartcreater() 同学的基本论点，究其根本而言，我都不反对。因此，我真不知道我们的所谓争议在哪里？
关于OO和性能的关系问题，我前面其实已经回答了。OO确实不是为了解决性能问题才出现。但是在现实中，因为不得要领的应用OO而导致性能下降的例子比比皆是。因此，将OO与性能问题结合起来讨论很有必要。
OO的根本思想，就我的理解，就是用领域问题最自然的结构来描述问题并建立起解决问题的模型。用smartcreater() 同学的说法，这大概就是“更合理的用计算机语言来描述现实世界”，而在我看来，就是“用现实世界最自然的方式来描述业务逻辑”。个人觉得：这两种说法本来就没什么本质上的区别。我的一点个人感觉是：smartcreater() 同学对“业务逻辑”或者说“业务”似乎存在有点狭隘的理解，业务的感念其实很广泛：所有的类型和模型无论其所在层次和领域，都服务于其自身的特定“业务”。在这一点上，smartcreater() 同学在“.Net Framework中包含如此丰富的基础类库，从底层到UI，一应俱全OO设计”一句中提到的所有类型也概莫能外。
至于“可以楼主的经历大多在网站层面！ 才出此言！！”，事实是，网站相关的开发经历顶多占我个人开发经历的1/3。Top
64 楼sunnf（sunnf）回复于 2007-03-13 08:20:01 得分 0
精采！！！继续关注。学习再学习！Top
65 楼sse33（宁静至远）回复于 2007-03-14 10:38:23 得分 0
LZ的言论开拓了我的视野，注意到oo和缓存的联系，但我个人觉得帖子的精髓不在LZ发表的文章，而是从而引发oo关于性能和扩张性矛盾的讨论，给我这些菜鸟可以更深的理解我为什么要用oo。延展性扩展性是基础，性能是关键。Top
66 楼aafshzj（生活需要breakthrough）回复于 2007-03-14 15:31:33 得分 0
sse33(宁静至远) ：
感谢你的留言。有一点大家可以讨论：那就是“性能和扩张性矛盾”吗？
我的个人感觉是：绝大多数现实情况（也就是非极端情况）下，性能和扩展性并不是0角度的契合，但也不是180度的矛盾。只不过要将二者同时驯服，需要在架构上好好下点功夫。
我的一点粗浅认识是：所有的指标，本质上都是对另一个指标：“个人/团队智力和经验”的挑战；我们所有的权衡与其说是在各项项目指标之间进行，不如说是在各项项目指标+“个人/团队智力和经验”指标之间权衡。
Top
67 楼thoughtworks（）回复于 2007-03-14 20:09:49 得分 0
有见地！我刚加入了一个所谓的asp.net团队搞一个站点，那些人想也不想，就要搞什么静态页面，搞一大堆存储过程，我在想这玩意儿真有那么神么，现在搞得很混乱，我要接手搞代码维护，连个开发文档都没有，全要让我自己琢磨那些匪夷所思的东西，貌似他们自己都不知道当初是怎么写出来的，站点开通了几周竟然连负荷测试，访问量都没统计测试……，，，，就闭着眼睛在那说静态的快，存储过程快，，，，……没办法，刚进去，没有任何说话的分量……你要是我的技术主管，那我铁定跟你干！Top
68 楼thoughtworks（）回复于 2007-03-14 20:13:14 得分 0
补充一下，我认为持久化对象世界这个说法中的“持久化”值得考虑，，，这个持久该怎么定性定量？？？？持久有多长？永远？或者维持1秒钟便足够？Top
69 楼aafshzj（生活需要breakthrough）回复于 2007-03-15 11:34:46 得分 0
thoughtworks() ( ) :
感谢你的留言。
静态页面也是可以搞得，但要对所有的页面内容进行分析：哪些内容是基本不变的，哪些内容是经常变化的，哪些内容中的哪一部分是变化频繁的....
有一些网站除了管理页面，几乎不需要动态页面。有的则必须使用动态页面。大多数情况介于二者之间。
即便是静态页面往往（除非极端情况）也需要好的架构，因为静态页面在大多数时候还是根据可维护的数据生成的。只不过因为变化缓慢，可以直接生成html页面罢了。Top
70 楼michney（最近比较闲）回复于 2007-03-15 16:43:38 得分 0
mark 一下，以后研究Top
71 楼aafshzj（生活需要breakthrough）回复于 2007-04-18 21:49:38 得分 0
自己顶！Top
72 楼haixj（会编码的流浪者）回复于 2007-04-25 15:42:52 得分 0
牛!不过完全的OO对于我们小公司混的没时间搞啊,为了MONEY也就管不了那么多了,客户能用就行Top
73 楼fstars（天天）回复于 2007-04-25 22:42:15 得分 0
正在关注OO，不过确实是要看项目规模了，一个就用1年的软件，还是开发的越快越好了。天天都在干这种事，郁闷。Top
74 楼zhongwanli（㊣【为了老婆，二次重构____然后升★★】㊣）回复于 2007-04-26 16:42:31 得分 0
需求是不断被激发的，所以OO所面临的应该是不断变化的需求。
DP，AOP也是为此。Top
75 楼z_teny（）回复于 2007-04-27 09:16:01 得分 0
请问下:OOP跟缓存存在着什么样的关系,我觉得一直在围绕着缓存在讲Top
76 楼amandag（高歌）回复于 2007-04-27 09:24:25 得分 0
不错,有启发,谢谢Top
