你一定要用J2EE的理由

Question

名字不都告诉你了吗“企业!企业!企业!!!”
关于J2EE的选择是Architect的工作，如果你没有做过企业开发，没有真正的经验，那你不可能做Architect，这也就不是你该问的问题，因为即使你知道了答案也没有用。

Answer 1

说实际的理由就是两点：1、无论是开发还是实施，确实高效方便；2、客户选择的；
当然这也和我以前工作在所谓的“大客户部”有关，这些客户大都听了非Java的东西（如.net之类的）就会“微笑”或皱眉的……

Answer 2

下面说一下我一定不用ejb的理由
我不知道大家有多少人在非分布式的项目中用了ejb，
我的感觉是ejb的执行效率实在太低了，尤其是在大
数据量的情况下。以下是我周末在家做测试的结果：
硬件环境：P41.7+512M
软件环境：wl7+oracle817
数据表：
account(
  id varcha2(4) PK, 
  balance number(4) not null, 
  type varchar2(10) not null
)所要执行的操作：读取account表中的id显示在页面上方式一:使用ejb
jsp+bmp(ejb1.1)或jsp+cmp(ejb1.1)，因为两者的执行结果一样
方式二:不用ejb
jsp
(说明一下，两种方式中数据库的连接均取自连接池)测试一：表中1条数据
使用ejb,执行时间46毫秒
不用ejb,执行时间16毫秒测试二：表中100条数据
使用ejb,执行时间1900毫秒
不用ejb,执行时间124毫秒测试三：表中10000条数据
使用ejb,执行时间170000毫秒
不用ejb,执行时间740毫秒我分析了ejb的执行过程是这样的：
1、建立连接-->返回所有记录的PK的Collection-->关闭连接
2、遍历返回的PK的Collection
  (1)建立连接-->处理第一条记录-->关闭连接
  (2)建立连接-->处理第二条记录-->关闭连接
  .........
  (n)建立连接-->处理第n条记录-->关闭连接
  操作结束
  
对比jsp的执行过程
1、建立连接-->生成纪录集-->处理纪录集-->关闭连接-->操作结束通过分析我得到一个结论，ejb处理的时候并不能返回纪录集，只
能返回所有记录的PK,然后再根据每一个PK，去数据库中找到相应
的纪录。由此带来一个很严重的问题是每条记录都要和数据库连接
一次，这样的话程序的执行时间会与记录数成正比。(上面的测试结
果也可以看出来)而jsp在执行的过程中只需要和数据库连接一次，剩
下的就是处理返回的纪录集了。这些还没有考虑ejb1.1中网络方面的
耗时。所以我认为非分布式的应用中（实际上的绝大多数情况）不适合
采用ejb
有人会说什么cmp,bmp,local,romote的问题，我再补充一下我觉得ejb之所以不好，最主要的原因是它问题不是你用bmp或cmp,还是local或remote，这些都是上层的问题。我觉得最主要是底层的一些问题，是ejb返回给客户端的是什么。它并不是返回给客户端一个ResultSet，而返回的是纪录集的主键集合。客户端根据每一个主键在给ejb发一个findbyprimaykey()方法，而这每一次调用都要让ejb和数据库建立释放一次连接。如果有一万条记录，就要建立释放一万次连接，这对系统的压力实在是太大了。再看看jsp如何实现，无论是一条还是一万条，数据库的连接只有一次，连接之后可以生成一个ResultSet，下面就是rs.next(),如果是一万条记录就是一万个rs.next()，这远比数据库的连接的消耗要小的多，从我上面的几次测试的比较就可以看出来。

Answer 3

EJB 2.0的效率就比EJB1.1快了不少，但是还是没有直接连接快，所以MS拿它的pet Stroe和j2ee的pet Stroe比试性能是很无耻的，大家说是吗？

Answer 4

jdbc_ejb又在骂MS了，呵呵，
其实也不尽然，公司总是为商业目的的，我们没必要去争论这个我是倾向。NET的，不过我承认J2EE的框架体系的确比MS。NET要完整成熟。
但是有的时候的确需要小快灵，而省去不必要的层次
大型解决方案还是J2EE适合，而且设计模式也是给J2EE量身定做的

Answer 5

M$一直很无耻，没什么的。另外其实你只要用了servlet/jsp，你就是在用J2EE了，J2EE != EJB

Answer 6

客户有钱，就用ejb
客户没多少钱，就不用EJB
EJB是烧钱的咚咚

Answer 7

要提高效率，请使用J2EE的设计模式，不使用ejb如何做不用浏览器的client啊，如何实现分布式