to ejb or not to ejb 2-JSP教程,资料/其他-JSP编程-idc中文资讯站-客观公证的IDC产业权威媒体,关注域名、虚拟主机、服务器、网络、开源技术资讯，整合运营商资源，客观评价各地机房带宽线路质量、IDC企业名录等信息

to ejb or not to ejb 2-JSP教程,资料/其他

来源：作者：发布时间:2007-12-27 06:09:08

ejb disadvantages
surprise, surprise, despite all the marketing hype over the past three years, adopting an ejb solution does present some disadvantages. even more surprising, despite what you may have read over the past six months about these disadvantages, they are almost all avoidable when you know how:

large, complicated specification: in defense of sun, no widely adopted distributed technology has avoided this pitfall; take a look at the corba specifications from the omg (object management group), or the architecture of microsofts .net platform. still, it would be good if there were a trail to follow in the specification for different roles. for example, ejb developers need only read chapters 6 and 9 of the spec to understand session and entity beans. additionally, in my experience two roles, not the six assumed in the spec, exist in practice: container/server providers and application providers, who build, assemble, deploy, and also administrate an ejb server. as such, the specification should reflect how ejbs are used in practice and how development teams are organized.
increased development time: i mention ejb development time in comparison to straight java class development, not to other distributed environments. ejbs do take longer to develop, and when things go wrong, they can prove more difficult to debug, particularly because the bug might not be in your code but in the application server/container itself. again, a difficult pitfall to avoid since the container gives you so much, but a disadvantage nonetheless.
however, timely and targeted training can solve this problem. knowing what the container/server should provide (by understanding the specification) and knowing how the container/server provides this (vendor documentation, sometimes augmented by training) will reduce ejb development time dramatically. on a technical note, an ide that supports the java platform debugger architecture (jpda) also proves invaluable in tracking down bugs.
added complexity compared to straight java classes: at a superficial level, you require three classes for every session bean, four for an entity bean, and you may additionally employ value objects to reduce network overhead, adding another class. and i havent counted the deployment descriptors yet, one that stores standard ejb information, the other with vendor-specific information!
the solution: auto-generation. tools like xdoclet reduce the amount of code you have to write, and its free! most ides feature auto-generation capabilities too, but they tie you to one vendor, and usually in a gui-driven mode too, which means no automated builds or tests -- not a great solution.
potential to produce a more complex and costly solution than is necessary: the potential complexity and cost is a corollary of disadvantage number one concerning the complexity of the spec. simply put, "if you dont get it, it will get you." that is, if you dont understand ejb, you wont take full advantage of it. moreover, you will misuse parts of it and reinvent others, making your solution less maintainable and one that fails to capitalize on the advantages that make ejb a good idea in the first place.
continual specification revisions: no sooner have you deployed your shiny new ejb application than you see a new specification with newer features, rendering your application obsolete before it hits the streets. this situation, however, is unavoidable. as ejb technology matures, loose ends in earlier versions are tied up and new features added. vendor release cycles contract in sympathy, and you need to move with them. companies today upgrade application servers much more rapidly than they did databases three or four years ago, placing additional pressure on already tightened it budgets.