到底装不装，懂的人自然知道，jboss的pojocache在你看来就如装懂一样，是的，我们装懂，不应该说上升一词，缓存单元不应该是对象，对象缓存不存在的，存在的都是装懂，可以了不？请戒骄戒躁，不需要装不装，你觉得不对就不对，以理服人，不是天下真理都需要你来审核。你认为cache不存在其他说法，你用你自己的观点来说明，别用这些show自己下限的词语来点评别人。
关于“cache的名字干嘛用的”，我可以告诉你犹如“车”一样，cache导出了什么是cache，车也一样，但火车，货车，战车，这些不是车？这本来就是抽象思维。cache只不过是一个统称概念而已，别把这些一拒排外。原文中把cache上升到支持DDD有错？还那样认为的，那就随便你了。
PS：若果还是那样的态度回复，请原谅我无视。
你说的对，首先你要明白不管是火车、货车，或者战车，这些都是车，必须要具备车的特征和特点，也就是说车的概念更加抽象，而那些更加具体，对于面向对象而言，当你设计一个程序，上来你就写class么？那么你的通用性，扩展性在那里？如果这是你的设计，只能说是垃圾。
至于说你不懂装懂，不好意，不是上升到这个阶段，你的阶段现在还是不懂，装这个词对你来说也具备一定难度。
既然你说到通用性，这就和上升出现相悖的地方，一切视为对象和一切视为数据相通？难道上升了，就回过头来想下面的，那么这样的上升有何意义呢？无论什么cache都有预存行为，都能提高效率，不过因为某样设计，而决定了cache到底缓存什么。若果cache就可以描述一切的话，还说什么对象呢？cache的上升过程，是伴随着缓存的内容，数据上升为对象，所以数据cache到对象cache是一种上升过程，对象到实体同理。这是一种最小单元思维，也就是这种cache缓存最小单元是什么。
车（火车、货车、战车），cache（数据cache，对象cache，实体cache），有何不妥？上升过程是说数据，对象，实体，有何不妥？你说类？不好意思，这里的上升过程不存在类的概念。数据类，对象类，实体类？上升过程的依然是数据，对象，实体，而非类。还是说你把类和对象搞错了？
你说某个设计是垃圾可以，这完全取决于你自己的个人观点。但这种上升思维并不存在错误。
关于你最后一句，我就当没看见算了，因为某些人总觉得自己的话能决定别人生死一样。在这里是论理，不像一些人像上帝一样论世。你应该指出我哪里不懂，哪里搞错，像你这样的上帝模式，不知道其他人会如何看待你。
[该贴被SpeedVan于2011-03-14 18:12修改过]
这不是上升的问题，这是本质的问题，整个计算机体系的基础是冯·诺依曼结构，只不过现代的编程语言和编译器让你不需要去关注这个问题，但是不关注不代表不存在。在存储这些数据的时候必须采用这种方式进行存储。
如果我跟你说cache，那么第一反应是什么？难道仅仅是存储对象？我想这个答案甚至不能覆盖计算机领域内超过三分之一的人群，更多的人的答案是缓存数据。
至于你说的数据，对象，实体，我想你这里面存在很大的混乱，请你分清楚那些是设计时（或者编译时）的东西，那些是运行时的东西，如果这些你都没有搞清楚，那么谈cache没有意义，cache只会存在于运行时，而不会存在于编译时。
而当你将cache作为设计对象的时候，那么你又仅仅将其设计为只能存储火车的cache或者存储车的cache么？我想任何一家公司想设计一套这样的cache系统，面临必然是破产。看看现在成熟的cache，存储object是必然的，那么什么是object，我通常理解为就是数据，描述一个东西特定状态的数据。对于cache并不关心你存火车或者存汽车。
而且在你设计应用的时候需要去考虑cache么？严重怀疑你现在还存在于设计的混乱期。不要只看两本书就夸夸其谈，人长两个耳朵一张嘴就是让你多听少说。
是的，设计应用不需要考虑cache，但设计架构呢？一种设计，一种架构。当你遵循一种设计时，很多概念就会定下来，例如SOA架构，CQRS架构等，至于一种架构为了生存，而支持多种设计，是商业的事。
“存储这些数据的时候必须采用这种方式进行存储”，“只不过现代的编程语言和编译器让你不需要去关注这个问题”，是的既然已经隔离了，还想回去干什么呢？我并没有否定存在的说法，这是一种上升思维，数据已经上升为对象。要不，按你这样的说法，“根据冯·诺依曼结构，所以对象是在否定数据？”上升过程不是否定存在的说法。
关于cache关注点到，到底是一直停留在数据，还是可以上升到对象，实体等概念。这是理解cache里最小单元问题，而cache本身的只是指缓冲存储，解决速度差过大的问题。也就是一切用作缓冲存储，解决速度差过大的东西或者行为都叫缓存cache。缓存本身是对功能目的进行定义的，并不是缓存内容，也就是只要满足上述要求，就是缓存。而数据缓存，对象缓存，实体缓存，是一种划分，只是这种划分因所缓存的内容，带有上升思维。cache是否需要满足全部思维，这是实现者的想法问题，但并不能否定上升思维，难道只能缓存对象的cache就不是cache了？只能缓存实体的cache就不是cache了？
单独谈cache，当然很多人会想到数据，因为没有context，因为这时的数据时概括，狭义上的数，对象，实体。这是一种象数思维问题。使用OO时，你还说“这是数据”？OO犹如context，它决定了在这个范围内所使用的术语。
关于设计和编译，不好意思，这里面并没有冲突，应该说毫不相关。就如C++编译器，就不能编译满脑子对象的C++程序？cache是一组概念，与编译时还是运行时无关。若果真要归到运行时，那么OO，实体等思维都是围绕运行时来思考的（因为现实就是一个运行时），与编译无关，难道你OO分析设计思维，要考虑到数据长度？要考虑堆栈？要考虑甚至到达01的问题？
关于是否cache支持全部，这是商家问题，并不影响思维，这取决于成本和思维的影响力，与思维本身存在没有任何关系。而cache存的是object数据？广义的数据，的确可以这么理解。不幸的是，全篇都在说狭义的数据，即数，没有对象概念的数。若果cache能存object，意思是缓存对象，这并非指数据，若果他既支持缓存对象和支持缓存数据，那么它可能受java语言，这个“不伦不类”所影响。若果换到其他纯OO语言，还有数概念？难道要到底层才有所谓的cache？呵呵，不能理解。
设计应用考虑cache？整篇文章有谈到应用？这是设计架构来支持设计的思考，难道对你来说只有应用，没有架构？很不幸，应用设计和架构设计，我分得很清楚。还是你一直都在混淆这些概念？还有我可以谦虚地说：我看的书确实不多，但我也可以很自豪地说：我看的书远远不止两本。其实，看书多少，与发言质量直接有关么？对我来说，理解多少，才与发言质量有直接关系。看适量的书+多思考>>看很多的书+不思考。
“人长两个耳朵一张嘴就是让你多听少说”这句话不是你这么理解的，这句话的意思不是叫你真的少说话，而是叫你在广纳百言，而不是叫你闭口不说（犹如某些人对老子“无为”的理解），打个比喻，若果我真的错了，我不说，谁知道我错了？若果按你的意思，很不幸的是，现实中，我多听少说，那么对方就是多说少听了，到头来你还是得用这句继续批评我的对方。
其实我们在使用缓存时就是使用某种程度的实体概念。<KEY,VALUE>对中，KEY是唯一标识，VALUE就是实体。但是这只能描述一部分，因为DDD中实体当中还有关系，实体用对象实现，就得考虑如何保存实体关系。当然你可以用DCI去完全解脱关系，不过这已经是另外一种思维，另外一种架构了。
[该贴被SpeedVan于2011-03-15 10:50修改过]
[该贴被SpeedVan于2011-03-15 10:58修改过]
二位讨论的内容开始偏题了。对于同一个问题的理解，角度不一样，观点就会不同，甚至结论都不一样。
另外，对于问题的辩论不要谈一些充分条件、必要条件的问题。例如，我们说“毛泽东是伟人”，但是不要和我抬杠“除了毛泽东，就没有伟人了？！”。这样的辩论没有意义。
总体而言，我支持SpeedVan的观点。按照字面意思和目前普遍的应用，cache的使用就是提高性能，如果考虑到对象生命周期管理，确实是思维的升华。为什么不能站在作者的角度理解问题哪？
我没看到两个抬杠的理论在哪里，只看到了两个愤青
说实话，看完你的帖子我都不知道该怎么回帖子了。
首先给我的感觉就是思维的混乱，为了驳斥而驳斥，却没有自己的观点，而且中间有很多自相矛盾的地方，而且对于cache处于什么期根本无法感觉与判断。希望你能够写一点真正是阐明你自己观点的东西。说明你对cache的认识。
愤青···我愤的是，希望指出错误，或者提出观点，而不是上帝模式。对于任何观点，任何纠正，没有什么可愤的。
而这篇文章说出的观点是普通的对象cache继续上升到支持DDD的实体概念，而回复上的争论是，cache有没有所谓的上升过程。可以看出，某些回复是认为没有，cache就是数据cache没有所谓的对象，实体概念。而我指出的是，cache并非具体的，是一组概念，当中，不能通过存什么来确定是否是缓存，而上升思维存在于cache缓存什么，但并没有否定cache的概念。其实这类上升思维一早就用到很多，如硬盘，硬盘存数据没错吧，那么把数据上升为文件呢？因为某种需要，硬盘只存放图片，那么文件继续上升为图片，图片硬盘不可？若果套上上面的反对方的意思就是：硬盘就是存数据，没有所谓文件，图片的概念。所以我对此作出反驳，若果数据到对象再到实体，是一种上升过程的话，那么数据cache到对象cache再到实体cache也是一种上升过程。若果带有“就是存数据，没有其他概念”去思考的话，现在很多东西早就不需要了——游戏中创建角色，不，是数据。系统创建文件，不，是数据。你收到短信了吗？不，是数据。-。-，某些人硬要认为我也没办法了。
总结，我并不是指这些不是数据，而是指出，这些数据可以上升思考，cache也同理，cache缓存的是数据，但我们上升到对象，于是有pojocache了，我们再上升到实体，于是又有entitycache了。我自己尝试把聚合根平铺缓存时，就感受到，对象和实体大大不同，当中感受最强烈的就是普通的对象cache缓存聚合跟的话，实体关系会遭受破坏，也就是自己建立还原关系机制+对象缓存=实体缓存。
若果我矛盾了，请你指出，既然你知道我矛盾了，那么也知道是什么矛盾了，对吧？若果真的是矛盾，我虚心求教，不过别跟我说凭感觉。感觉我没有观点，还是你读不出我的观点呢？观点上述再次谈到了，至于论据上面也有点，之前的回复也有。
最新一篇文章：
DCI的AspectJ实现
使用Spring来实现DCI，那么在Spring中配置了实体类:
|
那么我们就不能用这种配置，要从Hibernate获取，不知加了Annotation的User能否从Hibernate中获取出来，这是一个关键。
我个人的思路是：无论能否取出来，都要断绝User和持久层Hibernate的直接耦合，按照DDD还是要做一个Respository层，在这个层将Hibernate获取的User，转换为加了aspectJ/spring元注解的User，然后存在内存中，如果你每次请求都这么转换，那么很费性能，无疑第一次存在缓存中，以后供每次请求使用。
但是无论如何，我们已经注意到，在Spring管理的业务层，已经对实体类加了@AssignmentsRol之类元注解，也就是不能不管模型实体类了，下面的问题是：模型实体类的对象生存在哪里？
我们很多人谈到对象，就认为是光溜溜的对象，对象有生存空间，万事万物都有场景和生存空间的，也就是边界，如果没有懂这个意思，可以看看我的道德经新解。我有一句俗语：屁股决定脑袋，在我的新浪微博中已经阐述其本质，实际是屁股位置不同，角色就不一样，决定了其思维角度不一样，这是典型的边界环境决定其内部事物的一个延伸。
回到对象上来，对象的生存空间两个：一个是数据库，躺在里面睡觉，一个是内存，活动的，我们平时讲的对象都是活动的，在内存中的，那么缓存和内存有什么区别？缓存就是内存，只不过是有边界的内存罢了(边界：时间和空间上边界：时间上不是用完就丢，存在一段时间；空间上不是占据所有可用内存，而是有一定大小限制的内存)。
http://www.jdon.com/jivejdon/thread/39889/30#23132348
[该贴被banq于2011-03-17 11:42修改过]
而关于之前说到要用cache来做web的目的，是让别人感受到，实体应该一直存在于领域，是活生生的，不是死翘翘的（提出目的所在）。cache不是永久存放，但是是常存。LRU和内存数据库思维也是出于此。LRU的目的是向内存数据库靠近，我们的本来目的是想把所有数据都加载到内存，但硬件问题，所以只能通过LRU把常用的加载，让使用者感到数据就在内存当中，假设100%命中，那么就相当于内存数据库了——数据都全部在内存中了。从这里可以看出cache只关系到预存（缓冲存储），怎么预存，预存什么都没有改变cache的意义。那么上升后的实体缓存达到了什么呢？1、拥有原cache的所有特征。2、作为实体的存放地（因为没有cache，没有map，就没有地方放实体了，到了数据库是死的）。而hibernate的ehcache，我是一直不看好的，因为他只作为持久化框架，并不是业务框架，它并不知道业务需要怎样的缓存，Hibernate某种时候使用二级缓存没有效果或者效率更低也是这个原因。模型应该与业务相关，与持久无关。所以个人感觉Spring支持cache是一种进步，若果作为一种支持能额外配置成实体cache则更好。
>>“缓存就是内存”
banq真是一语中的，我说的“只是一个内存接口”也是这个意思，想不到banq用更自然的语言把道理说出来——空间。其实我之前也就说过若果内存是足够的，那么我用map即可，不需要用LRUcache（LRU+CACHE），可惜现实不够。在这里可以看出目的，cache跟map的目的是一样，预存数据到内存，而且是向“数据全部都在内存”靠近，只是软硬件的一些原因，导致技术选择了LRU+cache，what和how而已。所以这里就如banq所说cache就是内存一样（若果内存是够用的，那么居于这种目的的map也是内存了）。
以上是文章的初始论题。
之于后来，论题变成是否存在上升一说了。也就是xihuyu2000 认为偏题的道理。不过也没办法，别人提出的问题总得要回复。
[该贴被SpeedVan于2011-03-17 12:08修改过]
[该贴被SpeedVan于2011-03-17 13:49修改过]
我想如果cpu的cache用GB来计算，那么banq一定说那才是缓存。
缓存概念跟大小有关么？看其作用吧，不是起缓存储存作用的，再大也不是。某个时候硬盘也相当于缓存，如玩一些网页游戏，本来并不用下载到本地的，下载到本地是为了什么呢？如internet临时文件，也是一同保存到硬盘上，下次访问则不用在请求服务器，直接本地获取（其中一个很明显的特征：当加载图片后，即使服务器改变该图片，本地再访问也是旧版的图片，解决办法是，资源地址加入随机数，但这样失去了缓存的功能了）。
从以上可见，缓存就是起缓冲存储作用，解决速度差问题的存储器。
说的非常好！！
我觉得你总算认识到什么是缓存了。
缓存就是将需要下次可能读取到的东西先暂时放起来，以提高系统的整体速度。
比如你的硬盘，它上面就有缓存，对于你所使用的操作系统而言，上面有文件系统，再上层有各种应用，可能有word，excel，文本文件等各种各样的文件，可是你的硬盘缓存需要知道你这次缓存的是word或者excel么？或者说硬盘缓存只针对于word进行缓存而无法支持excel的缓存？所以对于缓存系统而言，不需要去了解需要缓存什么，他知道的只是数据，而不关心类型，它将你可能要进行访问的东西先保存一下，用以提升用户感受而已。
而且对于一个系统而言，不管应用设计或者架构设计都不应该率先考虑缓存，因为架构中即使没有缓存也应该是可以运行的，就像你说的“缓存就是起缓冲存储作用”，如果可以不考虑缓存的话，那么你为什么还要一定要强调缓存的是什么东西那？
而针对banq的那句话是因为我始终觉得他将缓存变成了持久层，缓存就是缓存，持久层是持久层，两者出现的时期、作用不同，不希望他再误导别人。
注意，我再强调一下：缓存=有边界的内存，就像：人=XXX的高等动物一样。所以，我的概念就是缓存就是内存。
所以，如果把你的话“因为架构中即使没有缓存也应该是可以运行的，”换成“因为架构中即使没有内存也应该是可以运行”显然是错误的，不要因为内存不在那里你就可以忽视，也不要以为内存在那里你就可以无限制使用。
不要以为“无”你就否定“无”。
如果计算机做到7x24不停机，即使维护也只是逐个维护，有几千台或几万台服务器农场或云计算工厂中，如何需要持久呢？这时缓存就是持久。
所以，把你的话改成：
不管应用设计或者架构设计都不应该率先考虑持久，因为架构中即使没有持久也应该是可以运行的。
那么在架构设计不应该考虑持久，缓存内存又是“无”状态，那么率先应该考虑什么？对象的生命周期。
而对象生命周期是通过缓存来实现的，所以，否定之否定，又回到处于“无”的缓存（内存）当中。
为什么你会有“缓存就是将需要下次可能读取到的东西先暂时放起来，以提高系统的整体速度。”这个认识，那是因为你首先考虑持久，所以，才用缓存来解决持久，就象你首先要拉屎，才考虑吃饭，其实这个次序可能错了。至少在我倡导的新的架构世界里次序肯定是错的，正好反过来。先吃饭，再考虑拉屎，先考虑对象生命周期，再考虑对象的持久化问题。
再假设一下，如果计算机诞生一开始，内存就象硬盘一样便宜，无限制使用，你是否还在用“缓存只是提高读取速度？”，你会认为“硬盘是降低读取速度，但是能够永久保存”，但是如果告诉你硬盘就是闪存，闪存内存就是硬盘(至少百度现在用闪存替代硬盘了)，你的观点会改成怎样？
所以。角度不同，观点不同，没有误导之说，只有误听之嫌疑。
[该贴被banq于2011-03-19 18:13修改过]
[该贴被banq于2011-03-19 18:18修改过]
首先“因为架构中即使没有内存也应该是可以运行”这句话在现在在某些系统已经实现了，您可能听说过非易失性内存，现在已经逐步在一些重要的系统上开始使用了。
我们暂时不去考虑这些特殊情况，就按照您的说法说下去，不管是单个小机或者几千几万台云计算的系统，那么当你希望找到一个数据，都避免不了的一个过程就是寻址，那么我相信从成千上万的计算机中找到数据速度肯定要慢于单机寻址（总线速度通常高于网络传输，包括光纤，而云计算还需要对数据进行校验，也需要时间），所以云计算更需要缓存，也就是说云计算并不是缓存，而是云计算仍然需要缓存。
而且现在硬盘的速度已经超过计算机诞生时候的内存读取速度。（一台最普通的PC Server硬盘速度已经达到了6G），内存消失了么？没有，那么未来内存速度更快就也不需要cpu的cache了么？可是服务器的cpu的cache正逐渐变大。也就是说，为了更快的读取速度，一定会将经常使用的东西放入更快读取速度的空间内。所以持久化是不能取代缓存，缓存也不能取代持久化,这是两种不同目标设计的东西。
[该贴被ACoder于2011-03-19 22:38修改过]