JAVA做三层的问题（高手请进）

EJB并不复杂，效率？WHO CARE，那是硬件的事，现在能开发出稳定的程序就够了！

> EJB并不复杂，效率？WHO CARE， not agree with it. If the application do not need Transaction, Clustering, High Security, Resource Pooling, it is not necessary to use EJB. 硬件的事 == Money. To be a good technical person, one should provide the best solution for the client. Cost control is very important.

同意楼上的。
EJB可能并不是很麻烦，但是，用EJB来实现中间件时对整个系统的软硬件成本的增加确实麻烦。

呵呵，可以用rmi，不过太低层了点，没有什么高级的特性，不过很简单，对于非商用应该还是可以的，而且也没有什么软硬件的过高要求。

Transaction, Clustering, High Security, Resource Pooling原来是EJB的长项么？学习学习。
--------------------
我对三层乃至多层的一点理解：
数据的存贮、数据的处理和数据的表象区分开来就成了三层。
区别于以前的c/s，b/s都是客户端直接去访问数据层，得到数据在客户端处理，生成结果又直接存入数据层。
客户端：无非是让客户能够输入数据，看到输出。用浏览器可以做到，用应用程序也可以做到，其实浏览器就是一种比较全面的应用程序。
处理端：处理客户的数据，需要的时候与数据层进行交互。用什么？不觉得有什么特别的要求。比如说我可以用delphi搭建客户平台，用c程序处理用户数据，需要的数据可以存储在mysql数据库里面。
数据端：存储数据而已，用文本，xml文档，数据库各有各的好处，各有各的难处。数据库各种版本也是各有各的好处。
-----------------------------------
我也还不知道如何的搭配是个最好的解决方法，因为会的（技术）很少，有的（软件）也不多，无从试起。

用Session Bean做中间层的效率还是可以的
而且用ejb可以做到群集，可以提高性能，适应大型的应用

Sun的J2EE Paterns的Multi-tiers提到了5层，似乎中间的presentation tier/business tier/integration tier就是你所说的中间层，我想你应该重新打造你中间层的结构。
正如楼上说的，Client tier只是负责显示数据和将客户数据pass给中间层，至于是browser还是java application这都不是问题。我们假设数据经过加工流向Client tier-- Resource tier->Integration tier->Business tier->Presentation tier->Client tier，这里面处于你所说的中间层的Integration tier和Business tier都是可以独立于数据的表现形式的，无论Client tier是browser还是java application，需要做的只是另外打造Presentation tier以适应不同的Client tier……

事实上，我是想用JAVA来做多层的中小型商业应用，而EJB好象是必须带一个J2EE服务器的。如：Websphere、WebLogic等。这样，就必然会导致整个软件系统的价格下不来。说白了，弄得不好就成了我帮IBM、BEA白打工了。这种事自然是我所不想干的。因此，我想多了解一些JAVA做三层的方法。
再次谢谢楼上各位的指点。分不够可以再加。希望有更多的人能不吝指教。

J2EE服务器也有免费版本的:JBoss

用EJB吧
无论是C/S,还是B/S....

现在开发一般用javabean作为中间层~~别忘了学习EJB哦~~，等有了它用武之地的时候，你就可以一显身手了
毕竟用EJB开发的大型系统不多

TO:cosmo(MoMo) 等你开发出稳定的程序后，再谈效率。
硬件=MONEY？君不见现在硬件的发展？？
现在有钱的多的是，上次做一个项目，不过是一个小网站，JSP+JAVABEAN，运行环境是两台SUN（SOLARIS）服务器。中国程序员编程要精巧，效率要高，印度程序员先让程序稳定跑起来，在提高它的性能。现在用户首先要的是一个稳定的系统！！！！

稳定的系统也要視乎項目的預算, 我不是說EJB 沒有用, 我現在也正為銀行做EJB + XML (像J2EE 5 TIER)的系統, 因為是銀行, 所以TRANSACTION 是必要, 用EJB 是适合的方法. 但是不是所有系統都要用上EJB.
编程要精巧, 效率要高==> 用SERVLET 一定比用EJB 快
印度程序员先让程序稳定跑起来 ==> 講的是CODING LEVEL 不用太精, 但FRAMEWORK DESIGN, 需求分析一定要做得夠. 用SERVLET 就可以做得好的系統, 就要用SERVLET, 用EJB 才做得好, 就用EJB. 若人家的要求是簡單的系統, 預算用五六万左右, 如果用EJB 的話, 買不到足夠性能的SERVER, 會有稳定的系统嗎?

废话，5、6万的程序用什么ejb，直接用asp就行了。我们的话并不矛盾，做系统当然要看具体需求，Transaction, Clustering, High Security, Resource Pooling当然都要考虑，只不过要根据实际分清主次。
做银行不考虑效率和安全性，不如不做！

From JavaWorld
http://www.javaworld.com/javaworld/jw-12-2001/jw-1207-yesnoejb.html?
Rules for choosing EJB
Choose EJB when you know your application will need to scale beyond initial low usage levels and support multiple, concurrent users.
Choose EJB if you need transaction management. For online catalogues or read-only systems with low user numbers, you probably don't need EJB. For financial systems or any system where you must preserve the ACID (atomicity, consistency, isolation, and durability) properties, EJBs are a must.
Choose EJB if you need a comprehensive security model.
Rules for not choosing EJB
Do not use EJB when you find no need for scalability, transaction management, or security and anticipate low numbers of read-only users.
Don't choose EJB if you don't need platform independence and don't mind being locked into one particular vendor. This rule isn't designed to be sarcastic; intranet applications serve as a good example where I would like to see as little complication as possible. Indeed, a solution like .Net could prove highly successful in such situations, even in a beta release.
Do not choose EJB if your team possesses no EJB experience (and you don't plan on ramping up or importing such experience).
Do not use EJB just because your company got a free set of licenses from vendor X.

调试易

JAVA做三层的问题（高手请进）

解决方案 »