当前位置：编程学习 > JSP >>
The rule book
At this stage, I list a set of rules to guide you in deciding whether or not to use EJB. That's basically what the EJB/no EJB decision boils down to: looking at your own unique project and applying these rules.
Rules for choosing EJB
Rules for not choosing EJB
答案：Alternative approaches
So, if you are really uneasy about going down the EJB route, what alternatives exist? Well, assuming you want to stay with Java or employ another mainstream technology, then the answer is -- not many. I've listed below the main alternatives.
Avoid EJB completely, yet still employ a Java solution
Don't use EJB; simply write straight Java classes. This solution means you must explicitly handle (or ignore) issues such as multithreading, scalability, and transaction management yourself. Now if these issues don't affect your scenario, then there is no value in using EJB (or any comparable technology), so writing straight Java makes sense.
If, however, you must address those issues, and you still decide to forgo EJB, then you must write systems-level code as solutions. Such systems code usually starts out as a couple of base classes with utility methods like getConnection() and closeConnection(), plus a couple of XXXManagers, then quickly mushrooms into your own custom version of a stripped-down container that must be maintained in-house -- not a good solution.
Adopt an EJB-friendly design
As another alternative, you can plump for a solution that makes it easy to adopt EJB at a later stage. A number of widely available design patterns make this choice feasible; in fact "Designing Enterprise Applications with the J2EE Platform" uses many such patterns. More often than not, the adopted solution is usually a Model 2 architecture, with good separation between presentation (JSPs) and business logic (servlets), in preparation for a more robust and scalable middle tier in the future.
Move to a completely different technology
If you wonder whether Java technology is right for you, then take a look at CORBA or .Net. Other options exist, but these two represent by far the main competitors to EJB/J2EE.
Don't think about going to CORBA if you think EJB/J2EE is overkill for your needs, as CORBA is at least as comprehensive. In any event, the J2EE platform has supplanted CORBA as the premier open standards-based, cross-platform enterprise computing solution. All vendors who previously sold CORBA implementations now offer J2EE implementations.
Meanwhile, Microsoft has been pushing .Net heavily. .Net is language independent and platform dependent (EJB is language dependent and platform independent). By and large, the design and feature-sets of .Net and J2EE map very closely. At present, in my opinion .Net provides no competition to J2EE. It simply hasn't been around long enough, and the architecture's key features -- particularly the common language runtime (CLR) and C# -- are new and untested in production-class systems. However, make no mistake, .Net will be a strong competitor; Microsoft led the way with DCOM (Distributed Component Object Model) and ASP (Active Server Page) and will continue to add good ideas and technology to the enterprise computing space.
Think out of the box!
If none of the preceding options float your boat, then you may consider other candidate technologies such as Jini/JavaSpaces or Sandstorm, which are not widely used:
- The Jini/JavaSpaces pairing has failed to attract any significant market share since its release, and is often found in an academic setting rather than in a commercial deployment. However, its simple model is easy to grasp, and it possesses the basic constructs required to build complex enterprise applications. I added Jini/JavaSpaces to this list because I am currently using it in an academic setting myself and appreciate its elegance. But I wouldn't use it in a commercial deployment as the backbone of my system just yet; I don't feel it has enough industry momentum or support. Your mileage may vary.
- The exciting Sandstorm technology addresses the issue of scalability exclusively, but does not handle security or transaction management. However, it might fit some business scenarios. I would love to see an application server use Sandstorm under the hood!
The rule book
At this stage, I list a set of rules to guide you in deciding whether or not to use EJB. That's basically what the EJB/no EJB decision boils down to: looking at your own unique project and applying these rules.
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.
 Figure 1. The main phases involved in deciding what technology to use. Note: This model applies to any technology, not just EJB. The goal is to end up moving into full-scale design and development with the right technology. 上一个：to ejb or not to ejb 2 更多图片编程知识:
CopyRight © 2012 站长网 编程知识问答 www.zzzyk.com All Rights Reserved
部份技术文章来自网络， |
