关于SPING与EJB的胡言乱语

谓分布式就是能够远程调用的就算是，例如B/S就是常见的一中
Ejb支持对象分布(也就是部署分布,我是这么理解的),不过我更喜欢用APP集群，设想谁没事愿意把不同的EJB组件分别部属在不同的APP中，然后对每个APP采用集群呢？针对现在出现的SPING 与EJB两种J2EE框架我觉的用哪个都可以只不过EJB编写比较麻烦有好几个类，我们可以用EJB的LOCALE 取代REMOTE，（它就是多了一个APP（JBOSS等）），但是如过用SPING 多了个SPING ，而且程序被绑丁到SPING 中，但是EJB就不同它是一个规范，用哪个APP都可以，他们都实现可配制的事物等，还有如果用到集群，对数据CACHE这一块是否SPING 可以支持同步等（不要告诉我用另外一个框架代替），随着WEB SERVICES的广泛应用这两个框架都支持B/S和C/S。所以综上所述，我喜欢用EJB，期待EJB3。0出来可以简化开发。就因为他是标准，而且考虑了所有的分布式中的问题，再加上强大的APP提供的功能，需要程序员只关注业务逻辑的开发就可以了，而且层次划分更好，试想SPING能否长久，能否提供如此强大的功能。用EJB使程序可扩展性高，比较长远。本来用一个APP就能实现的功能，非要程序员再去组装不同的框架如SPING+HIBERNATE（如有特殊的需求还要别的框架），试想自己组合这些框架所带来的效率是否比APP效率高呢？再说了，如果这样的话一个公司一套模型，招聘也不好找人呀，用了EJB就不要这么麻烦了，希望JAVA的世界能够统一，
共同努力把EJB给搞好。不要让程序员在选择上如此麻烦（这一点MS确实做的好）
说的对不对只是参考,本人只针对技术讨论.

Re: 关于SPING与EJB的胡言乱语 发表时间: Dec 30, 2005 5:33 PM 回复 发表人: blueoxygen    发表文章: 50 / 注册时间: 2005-06 谁说的用spring就被绑定了？ EJB时代EJB的脱离容器单元测试这种讨论还好长呢，用POJO的spring呢？ 请问你的项目里面有多少正如你所说EJB是分布式的？这就是为什么大家需要一个轻量级的框架，而不需要那么多stub interface EJB Object等对关心业务的人来说是buzz words. 要想统一？好办。大家学学SAP去，那才叫简化，关注业务。

Re: 关于SPING与EJB的胡言乱语 发表时间: Dec 31, 2005 10:05 AM 回复 发表人: banq    发表文章: 5902 / 来　　自: 上海 / 注册时间: 2002-08 两位讨论的都很好，都是一语中的。 其实Spring和EJB争论起源于轻和重的讨论，我偶尔翻起多年前的米兰 昆德拉“生命不能承受之轻”这本书。 记得当时在大学（89年左右）时，一个高年级的“传道士”突然以“生命不能承受之轻”为口头禅，引起我们小辈的羡慕和纳闷，挺拗口的啊。他还说：比喻是一种危险的东西，人是不能和比喻闹着玩的。至此，我以后不敢随便用比喻，老实用逻辑推理来说事吧。 希腊哲学家巴门尼德和中国老子一样，把宇宙氛围对立统一的二元：明与暗；厚与薄；重与轻。 尼采认为永恒的轮回的想法是最沉重的负担，最沉重的负担压迫着我们，让我们屈服于它，把我们压到在地，女人总是渴望承受一个男性身体的重量，于是最沉重的负担同时也成了最强盛的生命力的影像。 负担越重，我们的生命越贴近大地，它就越真切实在。 世界上重的东西很多，艺术上，贝多芬的音乐是重的；软件上：EJB曾经是重的，在我们心目中，重好像代表正统，代表一种主导。 生活中承受沉重负担；软件开发中，过去EJB的学习开发调试都是一种沉重，在我们承受“这些”之重时，我们向往灿烂美丽的生活或软件之轻了。 而这时，曾经轻盈美丽的Spring走到大家面前，受到我们疯狂的欢迎，从此可以摆脱沉重的负担了。 巴门尼德也说：轻者为正，重者为负；我们甚至相信：轻量框架将取代重量，成为正统和主导地位。 但是，重的真的残酷； 而轻的真的美丽？ 其实，当EJB 3.0推出；当Spring 2.0的程序需要特别的javac进行编译时，重和轻模糊了。 重和轻的对立是所有对立中最神秘、最模糊的。 谨以本文送给即将进入2006新年的Jdon道友们，希望在新的一年中，我们能够从更高高度来看待技术问题；让我们更加理性和冷静，因为世界是时刻变化中；而我们的思想总可能落后于它。

Re: 关于SPING与EJB的胡言乱语 发表时间: Dec 31, 2005 10:24 AM 回复 发表人: blueoxygen    发表文章: 50 / 注册时间: 2005-06 大家都在期待着EJB3 包括很多喜欢使用spring的人，当然，狂热的粉丝除外。 但是，EJB3不会再现当年EJB2推出时的辉煌了。

Re: 关于SPING与EJB的胡言乱语 发表时间: Dec 31, 2005 12:01 PM 回复 发表人: mythmoon    发表文章: 185 / 注册时间: 2005-03 EJB2没接触过，我也就知道一个概念！我入行的时候已经是POJO的时代了！ 不管控制层怎样还有持久化层怎样，tapestry是值得惊叹的好东西，设计和应用上。

Re: 关于SPING与EJB的胡言乱语 发表时间: Dec 31, 2005 2:48 PM 回复 发表人: banq    发表文章: 5902 / 来　　自: 上海 / 注册时间: 2002-08 今天在写方案时，手边正好有一份2002年的电子政务方案，其中提及使用J2EE的优点和特点，我觉得今天拿出来重温一下还是很有意义的，当然文中的观点都是当初EJB的主要优点；虽然今天构件技术发展迅速，但是温故而知新，当初为什么我们需要EJB？EJB给我们什么优点。 J2EE提供了一套企业级Java应用框架（一种标准），是一种利用Java 2平台来简化企业解决方案的开发、部署和管理相关的复杂问题的体系结构。 J2EE使用多层的分布式应用模型，应用逻辑按功能划分为组件，各个应用组件根据他们所在的层分布在不同的机器上。J2EE的初衷正是为了解决两层模式(client/server)的弊端，在传统模式中，客户端担当了过多的角色而显得臃肿，使用J2EE 的多层企业级应用模型将两层化模型中的不同层面切分成许多层。一个多层化应用能够为不同的每种服务提供一个独立的层，以下是 J2EE 典型的四层结构: 运行在客户端机器上的客户层组件 运行在J2EE服务器上的Web层组件 运行在J2EE服务器上的业务逻辑层组件 运行在EIS或数据库服务器上的业务信息系统 J2EE为搭建具有可伸缩性、灵活性、易维护性的商务系统提供了良好的机制: 保留现存的IT资产: 由于必须适应新的业务需求，利用已有的信息系统方面的投资，而不是重新制定全盘方案就变得很重要。这样，一个以渐进的（而不是激进的，全盘否定的）方式建立在已有系统之上的服务器端平台机制是我们所需求的。J2EE架构可以充分利用用户原有的投资，如一些公司使用的BEA Tuxedo、IBM CICS, IBM Encina,、Inprise VisiBroker 以及Netscape Application Server。这之所以成为可能是因为J2EE拥有广泛的业界支持和一些重要的'企业计算'领域供应商的参与。每一个供应商都对现有的客户提供了不用废弃已有投资，进入可移植的J2EE领域的升级途径。由于基于J2EE平台的产品几乎能够在任何操作系统和硬件配置上运行，现有的操作系统和硬件也能被保留使用。 高效的开发: J2EE允许把一些通用的、很繁琐的服务端任务交给中间件供应商去完成。这样开发人员可以集中精力在如何创建逻辑上，相应地缩短了开发时间。高级中间件供应商提供以下这些复杂的中间件服务: 1.状态管理服务 -- 让开发人员写更少的代码，不用关心如何管理状态，这样能够更快地完成程序开发。(注：指有态会话Bean，而Spring目前没有提供这样的状态管理服务，Jdon框架则提供了) 2.持续性服务 -- 让开发人员不用对数据访问逻辑进行编码就能编写应用程序，能生成更轻巧，与数据库无关的应用程序，这种应用程序更易于开发与维护。 (注：这就是说为什么说数据库时代终结了) 3.分布式共享数据对象CACHE服务 -- 让开发人员编制高性能的系统，极大提高整体部署的伸缩性。(Spring没有提供缓存,jdon框架提供了，而EJB提供了强大的分布式缓存，当然今天我们可以将JBoss的POJO 分布式缓存分离出来，用在Spring或Jdon框架上，但是这些需要你的定制能力) 支持异构环境: J2EE能够开发部署在异构环境中的可移植程序。基于J2EE的应用程序不依赖任何特定操作系统、中间件、硬件。因此设计合理的基于J2EE的程序只需开发一次就可部署到各种平台。这在典型的异构企业计算环境中是十分关键的。J2EE标准也允许客户订购与J2EE兼容的第三方的现成的组件，把他们部署到异构环境中，节省了由自己制订整个方案所需的费用。 可伸缩性: 要选择一种服务器端平台，这种平台应能提供极佳的可伸缩性去满足那些在他们系统上进行商业运作的大批新客户。基于J2EE平台的应用程序可被部署到各种操作系统上。例如可被部署到Linux、或UNIX与大型机系统，这种系统单机可支持64至256个处理器。（这是NT服务器所望尘莫及的）J2EE领域的供应商提供了更为广泛的负载平衡策略。能消除系统中的瓶颈，允许多台服务器集成部署。这种部署可达数千个处理器，实现可高度伸缩的系统，满足未来应用的需要。 稳定的可用性: 一个服务器端平台必须能全天候运转以满足需求。因为INTERNET是全球化的、无处不在的，即使在夜间按计划停机也可能造成严重损失。若是意外停机，那会有灾难性后果。J2EE部署到可靠的操作环境中，他们支持长期的可用性。一些J2EE部署在WINDOWS、Linux环境中，也可选择健壮性能更好的操作系统如Sun Solaris、IBM OS/390。最健壮的操作系统可达到99.999%的可用性或每年只需5分钟停机时间。这是实时性很强商业系统理想的选择。 基于构件：它特点是编译码、独立部署的单位、由第三方进行组合的单位、无持久状态等，它具有可插入、更好的设计、更好的复用、方便的更新、实现与接口分离的优点。 索性来个2005该话题的总结： Java企业系统架构选择考量: http://www.jdon.com/artichect/java_ee_architecture.htm J2EE集群原理: http://www.jdon.com/jive/article.jsp?forum=121&thread=22282 Spring vs. EJB http://www.jdon.com/jive/article.jsp?forum=16&thread=18904 好像上面话题讲EJB比较多，本身就比较沉重，但是有人甚至说J道是绝对推荐重型的；那么又有些片面了。 Jdon框架在2005中主要进步是构造轻型框架，可以说是试图结合EJB和Spring的优点，还有经典软件Jive。从论坛上看，很多初学者几乎能很快跑通Jdon框架的应用系统；付出较少的学习成本；得到快速成型的小型应用系统，Jdon框架绝对定位在轻盈浪漫的小夜曲，它和重型的EJB有良好的沟通桥梁；它不必象Spring那样声嘶力竭地呐喊，试图从EJB手中争夺更多的市场。 但是，无疑，Spring在现代构件方面是起着领头羊和探索者的角度，在新年开始之时，他们是值得尊敬的。

Re: 关于SPING与EJB的胡言乱语 发表时间: Dec 31, 2005 3:03 PM 回复 发表人: banq    发表文章: 5902 / 来　　自: 上海 / 注册时间: 2002-08 上贴出谈到J2EE"支持异构环境"，其实这点过去EJB做得很不够，因此SOA的提出，将诞生更好更方便的异构环境整合。 这也是我曾经说过：SOA是工业界试图在过去EJB路线上深化和做大的又一次新的征途，当然这次征途中容器设计将吸纳Spring等优秀构件概念，打造细粒度 灵活的SOA基础平台，预祝：2006年SOA将有更大的发展。 相关连接：不要误解和小看SOA的架构思路： http://www.jdon.com/jive/article.jsp?forum=91&thread=22667

Re: 关于SPING与EJB的胡言乱语 发表时间: Jan 3, 2006 2:51 PM 回复 发表人: banq    发表文章: 5902 / 来　　自: 上海 / 注册时间: 2002-08 今天刚刚发现一个帖子： http://www.jdon.com/jive/thread.jsp?forum=16&thread=24486 初学者问：POJO既然是轻量的，就无需Cache了吗？ 不只一次有人这样问了，看出什么原因呢：初学者将POJO的轻量理解成代码简单了，一些人利用轻量这个含糊词语，容易让人产生吹一口气，代码就搞定的极端方向联想。 轻量表示一种高度松耦合的状态，它说明是一种细粒度的组件/构件，类与类之间、或这组件之间彼此可以完全分离。这样你使用时，可以自己点菜了，而不是象吃大食堂/大锅饭，不管你喜欢不喜欢，都给你。你没有了自己的选择权了。 轻量不是一个科学上严格定义的概念。而是从人的舒适感和灵活性方面评价的。 Java当初诞生时就以一种非常轻便的语言自居，轻量也反映另外一种意思：无需程序员关心太多通用机制，如内存管理；对象生命周期管理/状态管理。make it simple make it stupid，大道至简都是对轻量理想境界的定义，Java应该是一种更适合笨人使用的工具。 另外，轻量化概念必须是易于开发，不能学习太复杂，学习成本太高。 所以轻量是对工具的一种严格要求：对一个工具；既要求其功能全能又要求其使用方便，可见这是一个终极目标。 我们用手机这个比喻来说明：要求手机有打电话 又有MP3 有照相机，又有PC电脑功能；很显然初期，这个手机要有这么多功能，那么就很笨重，这时就有点象EJB2，当然，这样手机还是有人买的，当初手机砖头那样重也还是有人用的，因为没有更好的，这就象EJB刚刚推出，大家趋之若鹜一样。 但是，这时有人叫卖，我这个功能多，重量轻，象多普达手机刚刚推出一样。 但是，软件这东西和手机消费品还不一样，还更复杂，这又类似汽车了，日本汽车自称质量高；重量轻；价格便宜；但是他如果是通过减轻钢板厚度来达到这个目的，那不是对消费者欺骗吗？ 所以，对于自称是轻量的东西，还是需要以批判眼光看待它，当初Spring推出时，我就以这种态度看待，被人笑话落后。 所以，如果你觉得Spring使用方便；灵活，那么就可以选用它，但是如果你有大量用户状态；或者需要集群并发访问；或者分布式事务机制，那么你还是要选用EJB，因为目前Spring没有提供这些功能，当然我不是指责Spring象日本轿车偷工减料，但是如果它过于逼人，而且宣扬：without EJB，无需EJB了，那不是有点类似日本轿车那样欺骗大家了？ Spring可贵之处在于其使用AOP的探索，但是不能放大这种探索，就象我设计Jdon框架，我认为是创新，别人还说成是拼凑，而洋人日本人“偷工减料”之嫌，却奉之若婺。 我不想引申到民族等专业以外的事情，但是这个世界是相通的，否则初学者真是想普通消费者被搞得一头雾水，这也是我一直说：选择权在你自己，可是你认识自己吗？你能把握自己吗？

Re: 关于SPING与EJB的胡言乱语 发表时间: Jan 3, 2006 3:10 PM 回复 发表人: banq    发表文章: 5902 / 来　　自: 上海 / 注册时间: 2002-08 那么为什么有那么多老外坚信Spring会提供一个轻量解决方案，虽然它目前一些功能没有提供，但是老外包括我也认为这些（状态管理 集群等）只是时间问题和工作量问题，为什么会这么说：肯定是基础理论方面发生重大突破，也就是设计概念上有重要突破，设计理论和软件产品如同基因和医学一样，一旦设计/基因取得重大突破，就会有大量新的药品或产品。 那么Spring依赖的设计概念是什么呢？当然是Ioc模式和AOP，这些我早就在Jdon设计研究栏目中解析并通俗化表达。 但是由于众多国内程序员基础教育没有学过设计模式，不知道设计和软件产品的关系，所以，对Spring这样一个Ioc/AOP产品疯狂追捧，而且有些别有用心的所谓高手（有些人不懂模式；有些人懂一点，但是有其他想法）利用这点和我诡辩！ 采用吐沫星子淹死你的策略，可惜很多初学者就如同一般消费者面对大量传销诱导，能不动心吗？ 软件产品是所有领域中最复杂之一，能够坚持发出一种理性中立声音，对于用户消费者的架构选择是必要的，当然也要受监督和竞争的。这也是Jdon的定位之一吧。

Re: 关于SPING与EJB的胡言乱语 发表时间: Jan 4, 2006 2:59 PM 回复 发表人: banq    发表文章: 5902 / 来　　自: 上海 / 注册时间: 2002-08 JSR-220, EJB 3.0, reaches Proposed Final Draft 最终正式版本将进入倒计时。 http://www.theserverside.com/news/thread.tss?thread_id=38198 TSS这个帖子里也有讨论EJB3 Spring POJO等概念，这些概念都曾经在我们这里激烈讨论过，有耐心的人可以仔细阅读。

<script type="text/javascript"> </script><script src="http://pagead2.googlesyndication.com/pagead/show_ads.js" type="text/javascript"> </script> name="google_ads_frame" marginwidth="0" marginheight="0" src="http://pagead2.googlesyndication.com/pagead/ads?client=ca-pub-2190557680964036&dt=1141237610750&lmt=1141237610&alternate_ad_url=http%3A%2F%2Fwww.jdon.com%2Fsales%2F468x60.htm&format=468x60_as&output=html&channel=1140201804&url=http%3A%2F%2Fwww.blogjava.net%2FSchumann%2Farticles%2F32657.html&color_bg=eeeeee&color_text=000000&color_link=000000&color_url=666666&color_border=eeeeee&ad_type=text_image&cc=11&u_h=768&u_w=1024&u_ah=715&u_aw=1024&u_cd=32&u_tz=480&u_java=true" frameborder="0" width="468" scrolling="no" height="60" allowtransparency="allowtransparency"> name="google_ads_frame" marginwidth="0" marginheight="0" src="http://pagead2.googlesyndication.com/pagead/ads?client=ca-pub-2190557680964036&dt=1141025430562&lmt=1141025736&alternate_ad_url=http%3A%2F%2Fwww.jdon.com%2Fsales%2F468x60.htm&prev_fmts=300x250_as%2C120x600_as&format=468x60_as&output=html&channel=1140201804&url=http%3A%2F%2Fwww.jdon.com%2Fjive%2Farticle.jsp%3Fforum%3D16%26thread%3D24513&color_bg=eeeeee&color_text=000000&color_link=000000&color_url=666666&color_border=eeeeee&ad_type=text_image&ref=http%3A%2F%2Fwww.jdon.com%2Fartichect%2Fjava_ee_architecture.htm&cc=516&u_h=768&u_w=1024&u_ah=740&u_aw=1024&u_cd=32&u_tz=480&u_java=true" frameborder="0" width="468" scrolling="no" height="60" allowtransparency="allowtransparency">

Re: 关于SPING与EJB的胡言乱语 发表时间: Jan 4, 2006 11:19 AM 回复 发表人: zhangmingjing    发表文章: 58 / 注册时间: 2003-07 spring2.0开始支持群集了。

Re: 关于SPING与EJB的胡言乱语 发表时间: Jan 4, 2006 8:47 PM 回复 发表人: banq    发表文章: 5902 / 来　　自: 上海 / 注册时间: 2002-08 >spring2.0开始支持群集了。 没有这么快吧？都没支持状态管理呢！没有状态管理，就没有集群中的failover，没有failover的cluster最多是负载平衡，不能算Cluster，我看其2.0更新中没有列出这条，因为这是一个重要性功能。

Re: 关于SPING与EJB的胡言乱语 发表时间: Jan 9, 2006 3:22 PM 回复 发表人: zdbj2ee    发表文章: 33 / 注册时间: 2003-08 spring我用了三年,对其也有一定的理解.用spring还有我自已在其基础之上的设计的抽象框架,我已使用的二个项目,非常成功.系统也很稳定. ejb这个东西,我向来对其没有好感.ejb中我认为为一能用的,就是无状态的sessionBean和jms,而这个东西,你可以用一个单实例来完成,不比这人无状态sessionBean的缓冲池快.看看实体bean吧,请问谁用. 还有就是测试了,现在开发我用测试驱动,测试用例在前.而ejb这个东西呢.你每次修改都要把到发布到容器中. 想想吧,有几个大项目会使用分布式. 见意大家,多看看实用主义的jod的 without ejb好书.

Re: 关于SPING与EJB的胡言乱语 发表时间: Jan 9, 2006 4:08 PM 回复 发表人: banq    发表文章: 5902 / 来　　自: 上海 / 注册时间: 2002-08 >在开发我用测试驱动,测试用例在前.而ejb这个东西呢.你每次修改都要把到发布到容器中 这算是EJB2.x一个缺点吧，也是MF向往POJO主要原因，但是我个人认为这不是非常重要的问题，因为你一旦以组件重用模块来装配EJB，试想每个组件模块都是经过测试的，那么到时装入容器通过率很高，我只是推荐我的一个方法，不可能要求所有人都采取这样方式，所以解决容器外测试也是丰富功能的一种： 以下EJB3.0两个新特性链接： Getting started with EJB 3.0 persistence out-of-container http://www.theserverside.com/news/thread.tss?thread_id=38276 Converting an EJB2 entity bean to EJB3 http://www.oracle.com/technology/pub/articles/vohra_ejb.html 另外，多谢zdbj2ee提供的经验之谈，能否透露一下你的Spring系统在处理Session这样数据状态时是怎么做的？其实这是我写本文关心的重要问题。 因为我们的每个系统都可能存在有状态的对象，如果没有，我认为有两种情况： 1. 该系统业务需求没有Session要求，那么这是一个不复杂的系统。 2. 即使有Session要求，你可能通过数据库实现，那么是一个依赖数据库的系统，依赖数据库的系统可伸缩性余地不大。

Re: 关于SPING与EJB的胡言乱语 发表时间: Jan 11, 2006 9:10 AM 回复 发表人: zdbj2ee    发表文章: 33 / 注册时间: 2003-08 session数据完全可以放在web层的session对象中. 在一个项目中应保持session中数据的最少化.我在做这两个项目时,保存在session中的数据只有登录用户的基本信息和一些安全数据. session中过多的保存数据不是什么好事.一般在jsp页面中我都会把session选项去掉． 如果你在做电子商务会用到购物车，你可以在这个用户进入第一个action时．把购物车的对象(内有存放数据＼删除数据/得到数据的方法)存放到session中.在用户结账时，调用结账action得到session中的数据，调用业务方法，业务方法再调用对dao完成结账．

Re: 关于SPING与EJB的胡言乱语 发表时间: Jan 17, 2006 7:21 AM 回复 发表人: dun    发表文章: 6 / 注册时间: 2003-08 看不下去了，哥们，你没弄明白斑竹是问你分布式解决session数据共享的问题么？ 或者我描述的简单点，机器1与机器2分享同一个session数据。 真郁闷。

Re: 关于SPING与EJB的胡言乱语 发表时间: Jan 19, 2006 12:15 PM 回复 发表人: zdbj2ee    发表文章: 33 / 注册时间: 2003-08 我们现在讨论的是如果处理session问题,谁说是分布式session问题,你把我上面的贴子看明白了,一些无知的人,把分布式当为神. 我是要否定分布式,而你且说什么,分布式session处理问题.有病

Re: 关于SPING与EJB的胡言乱语 发表时间: Jan 19, 2006 1:39 PM 回复 发表人: dun    发表文章: 6 / 注册时间: 2003-08 我就在把问题描述清楚点，当处在服务器集群下的一台机器出现问题时，其它机器需要将他正在处理的session接手处理；因此也就涉及到session分享问题，这也是spring等轻量级框架没有考虑到的问题； spring不错；能在applet级别的程序都提供容器服务，但是在分布式这里可以说是一个弱点； 而搂主问你的问题就是在纯粹使用spring当容器的程序中，如何更好的处理session信息同步的问题，例如：使用数据库保存session状态（或者称为持久化session）是一种解决方案，但是会增大数据库的压力； 可惜你答非所问，竟然说的是单jvm如何更好的使用session的方式； 没有人把分布式当神，只是我们有的程序要跑在这种环境下的，我们不是不喜欢spring的相对简单，也不是不厌烦ejb的复杂，但是spring在于分布式，异步调用或消息机制上还存在问题； 我想包括搂主在内都一直在致力于写一个能像开始的spring那么简单，又能包含EJB事务处理，分布式，异步等功能的企业级框架； 作为一个技术人员本身将立足点完全置于一个框架或者技术都是非常片面的，更何况这个技术仍然在发展；倒是小兄弟你需要好好看看啊，这里是技术论坛，不要随便说别人有病，显得自己素质不高，大家一起讨论技术，有分歧可以讨论但是你要是变相的问候我或者谁的家人就不好了吧，都文明点，你说呢。

Re: 关于SPING与EJB的胡言乱语 发表时间: Jan 19, 2006 4:29 PM 回复 发表人: banq    发表文章: 5902 / 来　　自: 上海 / 注册时间: 2002-08 呵呵，你们两位误解了，也不要吵。 我提的一个话题时Session处理，正如zdbj2ee所提出的那样： >如果你在做电子商务会用到购物车，你可以在这个用户进入第一个>action>时．把购物车的对象(内有存放数据＼删除数据/得到数据的方法)>存放到session中.在用户结账时，调用结账action得到session中的数据，调用业务方法，业务方法再调用对dao完成结账． 我是要等这个答案，购物车我们会放置到HttpSession中，那么如何放在HttpSession呢？无疑是通过request.getSession等命令或Struts或JSF相关配置，那么你肯定需要一个操作HttpSession的action之类的操作类，那么购物车Model和对购物车的操作Process将是可能是在表现层中MVC中的Controller部分，如果用struts也就是要编制一个action类操作httpSession中的购物车。 但是我们知道，购物车是一个业务Model，对购物车Model的操作也属于建模的一部分，象购物车这样的重要业务模型应该是在业务层实现，而不是表现层。但是因为Spring容器没有提供Session操作，就使得我们在业务容器中实现Session方面得操作，只能使用上述原始方案。 想像一下，如果我们购物车在业务层实现，业务层框架如Jdon Framework提供了Session操作，那么我们几乎所有业务功能都可以在业务层实现，表现层的MVC中的Controller将只成为流程调度，而这些都是可以使用XML配置实现，无需太多代码，JSP页面也是XML格式的标签库。 这样，我们就可以快速开发一个J2EE系统，而不用经常在考虑：哪些放在action中调用，哪些放在业务容器中调用，这种选择很浪费时间，而且Spring这样容器无法提供对HttpSession数据操作，使得以后拓展有关Session操作时，只能将这些POJO从Spring容器中移植出来。 我讲这些，无疑是从开发快速性和功能完整性对Spring一个期望，但是也请他们在功能没有完整之前，不要狂叫without EJB，而且也不要请一些不等实战的高手不要在各种媒体上用繁话似景的理论来误导实战者。 欢迎zdbj2ee提出更多实战中质量高、开发速度快的解决方案，

Re: 关于SPING与EJB的胡言乱语 发表时间: Jan 20, 2006 12:10 PM 回复 发表人: zdbj2ee    发表文章: 33 / 注册时间: 2003-08 我这样使用 void ShoopCarUtils.add(HttpServletRequest request). void ShoopCarUtils.remove(HttpServletRequest request). List ShoopCarUtils.getAll(HttpServletRequest request). 这样的操作不复杂吧.这个Utils类,是有依赖性,它依赖于request,但SFSB就没有依赖吗。EJBHOME，EJBOBJECT，JNDI一堆对象。

Re: 关于SPING与EJB的胡言乱语 发表时间: Jan 21, 2006 3:48 PM 回复 发表人: dun    发表文章: 6 / 注册时间: 2003-08 好吧，看来是我理解偏差了； benq的讲法有点没听明白，“业务层框架提供了Session操作”？是指业务层对session对象的引用么，还是指将状态保持做成接口，然后针对HttpSession进行实现，还是怎么样？ to zdbj2ee： 我原来有这样的处理方式： 定义 状态保持器 类簇（这个类簇中包含一个针对http(request,session,application等)的实现），针对此类簇提供工厂，这样就可以跟框架结合是用了，不管是spring,ebj等等都行； interface SituationHolder void ShoopCarUtils.add(SituationHolder holder). void ShoopCarUtils.remove(SituationHolder holder). List ShoopCarUtils.getAll(SituationHolder holder). 这样我的业务曾面的东西以来于我定义的东西，而不是直接跟servlet包中的接口产生依赖； 在次道歉，看来我现在有点简单问题复杂化的趋势了，总是想的太多