crogers 2003-11-26 13:43
> SUN已经有了OSS的JAVA实现规范了
> http://java.sun.com/products/oss/

谁敢用？呵呵

missxkl 2003-11-30 11:06
crogers说的有道理，赞同

我们BOSS说，首先自己不犯错误，其次要等待对手犯错误

听说banq要在清华附近讲座，我们公司有人去听哦

steeven 2003-11-30 21:10
听楼主的意思性能是关键. 也难怪电信这帮犊子不给我发送明细账单,原来都卡你们这了:)

以前做过一个日本的51job, 大概听过介绍. 它们也是采用sp, 因为性能. 由于历史关系, 还在用asp. 整体上就是asp+sp. iis server和db server的比例好象是10:1. 我估计要是换jsp3:1应该差不多了.

你想采用hibernate可能不是好事情. 业务层要调用hibernate, 再频繁访问数据库. 有网络开销啊. hibernate的那点优势根本没出来.

所以一直觉得考虑性能的时候就别惦记模式了.
以后SQL中可以用.net写sp. 估计这就是性能的正解了.

不同的工具就象CS里面的武器,各有各的长处,灵活运用才是高手 :)

aliag 2003-12-04 19:42
个人觉得很多人不愿意用Ejb的主要原因是在于entity bean.(当然这方面的论述很多了).本人没有做过电信级别的软件,但是开发过也算是用户数(1000)和并发数(500)比较多的软件,我更趋向于用存储过程来实现大量的业务逻辑,这点和楼主的感想一样,虽然每次移植都很痛苦,但是速度的确很重要.entity bean也实现了一些cache,sql优化等,但是它毕竟没有完整的统计数据,无法像db和开发人员一样做处最优的sql语句.在存储过程和设计到查询的sql语句中,开发人员会对每一条关键语句想尽优化的办法,包括不用>而用>=这样的细小的优化都会想到,甚至专门找db的技术人员咨询,我想无论entity bean的容器提供商如何优化也不会到这么细致的地步.其实entity bean的缓存机制和数据库的缓存机制类似,我们干吗非得加上一层呢?还是对自己没有信心吧.
至于session bean,的确是没什么好说的了,如果你还是对他不满意,就是一个结论,别用java,用c算了.
crogers 2003-12-04 23:37
> 听楼主的意思性能是关键.
> 也难怪电信这帮犊子不给我发送明细账单,原来都卡你们这了:
呵呵，发现这一句，既然现在在电信打杂，就回吧
长话是肯定有帐单的
市话是没有的，这是电总规定
原因是旧的交换机没有，当然，现在有很多交换机是新的了，可以记录了
既然有些有有些没有，自然只能对外说没有，因为客户平等嘛，;ppp~~~
tooom 2003-12-10 12:40
所谓速度慢，仅仅从软件角度考虑是不够的，还要考虑硬件
missxkl 2003-12-11 11:50
硬件是有限的
但数据库因为应用的原因成为瓶颈时
换再牛的机器也没什么效果。
在我们来说，性能确实是第一位的
下面我们可能在系统管理中使用hibernate，试验一下
其实还是DAO+jdbc直连速度快
whitefire2001 2004-01-20 11:50
早就知道电信的水平低，不过低到这种程度还是超出我的想象。 问题不在于EJB，在于有没有中间层，好的中间层设计可以让效率提高很多。数据库1000多个表？ 用共享数据模型没？
sprsong 2004-01-29 15:43
作计费有时候就是在数据库里取些数据，再生成另一些数据放到库里去，完全是在单纯的数据运算，jsp只是提供一个开始的触发。
这种情况下，用ｓｐ直接在数据库里操作数据很惬意，游标用起来也很方便。如果把所有有的数据都取到ＥＪＢ里再用复杂的算法做就舍近求远了。有好多操作在数据库里只需要一个命令，而在ＥＪＢ力就需要几百行的算法实现。
huntgf 2004-01-30 02:10
liuyi 2004-02-26 09:38
帮你顶一下:)