23,406
社区成员
发帖
与我相关
我的任务
分享喜欢java并且喜欢讨论的朋友们进来看一下，尤其是jdbc_ejb和zez两位兄弟
http://expert.csdn.net/Expert/topic/2285/2285944.xml?temp=.2706873
大家去看一下这个贴子
不过注意：
不要再回这个贴子了
jdbc_ejb 你应该经常和那个微软的MVP 5drush 讨论了，我建议你以后不要和他讨论了，根本没有意义，这个讨论是他叫我去的，结果大家也看到了。
事务处理是非常重要的一个部分，在微软的.net中如果要用分布式事务处理的话，如果都是sql server的话，要用COM+的知识，我想有一些人会知道吧，我觉得比EJB复杂，另外它竟然不支持 异构数据库的 事务处理，我无言了， 大家说说吧.....
另外 5drush 认为 吹鼓手 和 弱智一样 是人身攻击，我也无言了
我可以说 我就是 java的吹鼓手，急先锋，有什么不对的吗？换他可以吗？
此外，我评价 佳软的总工 是因为我觉得作为一个总工来说，不应该对某个东西持全盘否定的态度，甚至对于技术不能太冒进，比如我在VC5下推出的产品，当微软的VC6发布之后
，不应该立即追随VC6更新自己的产品，而是应该等确认VC6成熟稳定了，没有什么bug了，才去在产品中采用的。当然了我说的话可能也激进了一点，但是我绝对没有侮辱人！！！
另外 我觉得做.net开发的待遇很比不上java的，java的前景是非常好的，如果你水平够高，那么你的待遇是相当可观的。目前你可以去个大招聘网站看看就一目了然了，或者你从招聘的待遇看看
我希望大家应该尽快向高水平迈进
我先转了一个贴子，
http://expert.csdn.net/Expert/topic/2289/2289362.xml?temp=.6338922
重申：
不要再回我上面题的贴子了
大家去看一下这个贴子
不过注意：
不要再回这个贴子了
jdbc_ejb 你应该经常和那个微软的MVP 5drush 讨论了，我建议你以后不要和他讨论了，根本没有意义，这个讨论是他叫我去的，结果大家也看到了。
事务处理是非常重要的一个部分，在微软的.net中如果要用分布式事务处理的话，如果都是sql server的话，要用COM+的知识，我想有一些人会知道吧，我觉得比EJB复杂，另外它竟然不支持 异构数据库的 事务处理，我无言了， 大家说说吧.....
另外 5drush 认为 吹鼓手 和 弱智一样 是人身攻击，我也无言了
我可以说 我就是 java的吹鼓手，急先锋，有什么不对的吗？换他可以吗？
此外，我评价 佳软的总工 是因为我觉得作为一个总工来说，不应该对某个东西持全盘否定的态度，甚至对于技术不能太冒进，比如我在VC5下推出的产品，当微软的VC6发布之后
，不应该立即追随VC6更新自己的产品，而是应该等确认VC6成熟稳定了，没有什么bug了，才去在产品中采用的。当然了我说的话可能也激进了一点，但是我绝对没有侮辱人！！！
另外 我觉得做.net开发的待遇很比不上java的，java的前景是非常好的，如果你水平够高，那么你的待遇是相当可观的。目前你可以去个大招聘网站看看就一目了然了，或者你从招聘的待遇看看
我希望大家应该尽快向高水平迈进
我先转了一个贴子，
http://expert.csdn.net/Expert/topic/2289/2289362.xml?temp=.6338922
重申：
不要再回我上面题的贴子了
...全文
请发表友善的回复…
发表回复
wilsonchung 2003-09-26
- 打赏
- 举报
right!
jackal81 2003-09-25
- 打赏
- 举报
哦????????????????????
nettman 2003-09-25
- 打赏
- 举报
好用就行，管它是什么东东！
Wnyu 2003-09-24
- 打赏
- 举报
up
Wnyu 2003-09-24
- 打赏
- 举报
Up
lynx1111 2003-09-24
- 打赏
- 举报
up
linfeng01 2003-09-24
- 打赏
- 举报
其实.net和Java的是各有优缺点，
我们不应该全盘否定对方技术的观点，
不管我们是.net阵营的还是Java阵营的，
目前我看到的情况是，
Microsoft的高手们很多时候不看好Java阵营的，
很多MVP都这么认为，
他们觉得.net已经为未来十年做好了准备，
为什么一定要用java。
一些Java的热衷追求者反而觉得Microsoft的东西都是垃圾。
其实对各项技术要综合角度的来评判，
不应该蔑视任何其他技术，
毕竟IT是精彩的，无论Microsoft，还是sun，or IBM。
ps：其实.net的待遇也没有你想像的那么低了，
我认识一个MVP，工作也不久，
面试的时候随便一个小公司都给他4000。
大家都好好加油，为了我们热衷的技术。
我们不应该全盘否定对方技术的观点，
不管我们是.net阵营的还是Java阵营的，
目前我看到的情况是，
Microsoft的高手们很多时候不看好Java阵营的，
很多MVP都这么认为，
他们觉得.net已经为未来十年做好了准备，
为什么一定要用java。
一些Java的热衷追求者反而觉得Microsoft的东西都是垃圾。
其实对各项技术要综合角度的来评判，
不应该蔑视任何其他技术，
毕竟IT是精彩的，无论Microsoft，还是sun，or IBM。
ps：其实.net的待遇也没有你想像的那么低了，
我认识一个MVP，工作也不久，
面试的时候随便一个小公司都给他4000。
大家都好好加油，为了我们热衷的技术。
op2618 2003-09-24
- 打赏
- 举报
up
caiyi0903 2003-09-24
- 打赏
- 举报
gz
Sundery 2003-09-23
- 打赏
- 举报
支持，虽然我不是特别的精通：）
支持~~~
支持~~~
baitianhai 2003-09-23
- 打赏
- 举报
关于TMC的petshop大战的另一种看法
http://hibernate.fankai.com/viewtopic.php?t=139
我虽然没有看过那些评测的代码，但从上面的介绍中，至少可以做如下的判断：
1、.net petstore的业务逻辑没有分层，是直接在业务代码里面调用ADO.net访问数据库的。
在Java软件设计中，这是典型的糟糕的设计。把访问数据库的代码直接写在业务逻辑，一旦数据库表有修改，整个程序都要改动。没有Java程序员会这样写软件。
这也证实了我对.net的一个评价，我前面就说过.net不重视架构的设计，适合于快速原型开发。但是对于大规模的软件，生命周期长的项目，糟糕的架构会导致无数的问题，甚至项目失败。
2、.net使用数据库存储过程来实现复杂的多步操作，并且声称在数据库可以里面处理事务。
这已经不是面向对象编程了，是面向数据库编程。软件的可维护性将完全取决于数据库中表，视图和存储过程的设计，一旦数据库中有修改，改动将是全局性的。这一点再次证实我上面的观点，不重视软件架构设计，软件偶合性高，可维护性太低，一旦软件规模很大，维护将变成灾难。
3、.net petstore没有用COM+，这等于是Java中不使用EJB。
如果把Java petstore的Session Bean都改为普通Java Class，把BMP(BMP现在没有人用了)，改成JDO来实现，双方才能进行对等的比较。一个根本不用EJB的软件，另一个完全用EJB，并且是效率最差的BMP(1:n的关系表要用n+1SQL，这个问题我前面帖子讨论过了，是根本不应该使用的技术)来实现，根本没有办法比。如果硬要比的话，效率不会在一个数量级上。因此该项测试中在诸多不利因素下J2EE petstore也未能比.net petstore效率低1个数量级。可见，同等条件下，鹿死谁手，尚未可知。
4、TMC写的Java petstore软件存在很多软件设计上的缺陷。
JNDI是非常耗时的操作，一次JNDI服务定位要耗时在秒级，一次JNDI查找要耗时在几百号秒级，居然不进行缓冲操作。那么每次调用EJB都至少要花1秒多的时间来获得该EJB对象的引用。
所有的EJB方法都声明为需要启动Transaction。Transaction操作不但消耗App Server资源，也会锁定数据库资源。频繁的，过多的不必要的事务会造成互锁，EJB调用的性能极低。
EJB查询结果不进行缓冲，每次使用都调用BMP去数据库取。对于在程序中通用的数据，应该在初次使用的时候加载，放到静态对象中缓冲。而.net就是这样做的。
所以该评测是完全没有意义的。而且我也相信MS不会轻易使用COM+，我感觉COM+比EJB慢多了，如果使用COM+，Java使用Session Bean＋JDO，测试结果很难预料。
http://hibernate.fankai.com/viewtopic.php?t=139
我虽然没有看过那些评测的代码，但从上面的介绍中，至少可以做如下的判断：
1、.net petstore的业务逻辑没有分层，是直接在业务代码里面调用ADO.net访问数据库的。
在Java软件设计中，这是典型的糟糕的设计。把访问数据库的代码直接写在业务逻辑，一旦数据库表有修改，整个程序都要改动。没有Java程序员会这样写软件。
这也证实了我对.net的一个评价，我前面就说过.net不重视架构的设计，适合于快速原型开发。但是对于大规模的软件，生命周期长的项目，糟糕的架构会导致无数的问题，甚至项目失败。
2、.net使用数据库存储过程来实现复杂的多步操作，并且声称在数据库可以里面处理事务。
这已经不是面向对象编程了，是面向数据库编程。软件的可维护性将完全取决于数据库中表，视图和存储过程的设计，一旦数据库中有修改，改动将是全局性的。这一点再次证实我上面的观点，不重视软件架构设计，软件偶合性高，可维护性太低，一旦软件规模很大，维护将变成灾难。
3、.net petstore没有用COM+，这等于是Java中不使用EJB。
如果把Java petstore的Session Bean都改为普通Java Class，把BMP(BMP现在没有人用了)，改成JDO来实现，双方才能进行对等的比较。一个根本不用EJB的软件，另一个完全用EJB，并且是效率最差的BMP(1:n的关系表要用n+1SQL，这个问题我前面帖子讨论过了，是根本不应该使用的技术)来实现，根本没有办法比。如果硬要比的话，效率不会在一个数量级上。因此该项测试中在诸多不利因素下J2EE petstore也未能比.net petstore效率低1个数量级。可见，同等条件下，鹿死谁手，尚未可知。
4、TMC写的Java petstore软件存在很多软件设计上的缺陷。
JNDI是非常耗时的操作，一次JNDI服务定位要耗时在秒级，一次JNDI查找要耗时在几百号秒级，居然不进行缓冲操作。那么每次调用EJB都至少要花1秒多的时间来获得该EJB对象的引用。
所有的EJB方法都声明为需要启动Transaction。Transaction操作不但消耗App Server资源，也会锁定数据库资源。频繁的，过多的不必要的事务会造成互锁，EJB调用的性能极低。
EJB查询结果不进行缓冲，每次使用都调用BMP去数据库取。对于在程序中通用的数据，应该在初次使用的时候加载，放到静态对象中缓冲。而.net就是这样做的。
所以该评测是完全没有意义的。而且我也相信MS不会轻易使用COM+，我感觉COM+比EJB慢多了，如果使用COM+，Java使用Session Bean＋JDO，测试结果很难预料。
baitianhai 2003-09-23
- 打赏
- 举报
另外说两句
写程序一定要有注释，最好先写注释，程序要清楚，让人很容易看明白
异常一定要正确处理，我不能想象在c#中 “如果有异常你不处理try catch，程序照样能编译通过”
写程序一定要有注释，最好先写注释，程序要清楚，让人很容易看明白
异常一定要正确处理，我不能想象在c#中 “如果有异常你不处理try catch，程序照样能编译通过”
mayanwei 2003-09-23
- 打赏
- 举报
._.
Andrawu 2003-09-23
- 打赏
- 举报
看过了。
up一下。
up一下。
