a. 问题
前台控制给出了一个基于MVC的，能有效管理用户与J2EE应用之间进行的复杂交互。这个模式可以使处理页面的现实顺序和用户的并发请求变得简单。并且使增加和改变页面现实变得更加容易。
另外一个常见的问题是，当EJB或者业务逻辑发生变化的时候，应用的客户端也必须随之改变。我们来看一下这个问题。
一般来说，为了表现一个账户中的用户，我们使用一个业务逻辑来表示账户中的信息，象用户名和口令，再用一个EJB来管理用户的个人信息，象爱好，语言等。当要创建一个新的账号或者修改一个已经存在的账号时，必须访问包含账号信息的EJB，读取个人信息，修改并且保存，这样的一个流程。
当然，这只是一个非常简单的例子，实际情况可能比这个复杂的多，象查看用户定制了哪些服务，检验客户信用卡的有效性，存放订单等。在这个案例中，为了实现一个完整的流程，客户端必须访问账户EJB来完成一系列适当的工作。下面的例子显示了一个Servlet客户端如何来控制一个用户订单。
A servlet that does the workflow required for placing an order
// all required imports;
// exceptions to be caught appropriately wherever applicable;
// This servlet assumes that for placing an order the account and
// credit status of the customer has to be checked before getting the
// approval and committing the order. For simplicity, the EJBs that
// represent the business logic of account, credit status etc are
// not listed
public class OrderHandlingServlet extends HttpServlet {
// all required declarations, definitions
public void init() {
// all inits required done here
}
public void doPost(HttpServletRequest request, HttpServletResponse response)
throws IOException, ServletException {
// other logic as required
// Get reference to the required EJBs
InitialContext ctxt = new InitialContext();
Object obj = ctxt.lookup("java:comp/env/ejb/UserAccount");
UserAccountHome acctHome = (UserAccountHome)
PortableRemoteObject.narrow(obj, UserAccountHome.class);
UserAccount acct = acctHome.create();
obj = ctxt.lookup("java:comp/env/ejb/CreditCheck");
CreditCheckHome creditCheckHome = (CreditCheckHome)
PortableRemoteObject.narrow(obj, CreditCheckHome.class);
CreditCheck credit = creditCheckHome.create();
obj = ctxt.lookup("java:comp/env/ejb/Approvals");
ApprovalsHome apprHome = (ApprovalsHome)
PortableRemoteObject.narrow(obj, ApprovalsHome.class);
Approvals appr = apprHome.create();
obj = ctxt.lookup("java:comp/env/ejb/CommitOrder");
CommitOrderHome orderHome = (CommitOrderHome)
PortableRemoteObject.narrow(obj, CommitOrderHome.class);
CommitOrder order = orderHome.create();
// Acquire the customer ID and order details;
// Now do the required workflow to place the order
int result = acct.checkStatus(customerId);
if(result != OK) {
// stop further steps
}
result = credit.checkCreditWorth(customerId, currentOrder);
if(result != OK) {
// stop further steps
}
result = appr.getApprovals(customerId, currentOrder);
if(result != OK) {
// stop further steps
}
// Everything OK; place the order
result = order.placeOrder(customerId, currentOrder);
// do further processing as required
}
}
以上的代码显示了一个单个的客户端。如果这个应用支持多种客户端的话，必须为每一个客户端制定一种处理方法来完成工作流程。如果有一个EJB的实现流程需要改变的话，那么所有的参与这个流程的客户端都需要改变。如果不同的EJB之间的交互需要改变的话，所有的客户端都必须知道这一点，如果流程中需要增加一个新的步骤的话，所有的客户端也必须随之修改。
这样一来，EJB和客户端之间的改变变得非常困难。客户端必须对每个EJB分开进行访问，致使网络速度变慢。同样，应用越复杂，麻烦越大。
b. 建议的解决方法
解决这个问题的方法是，把客户端和他们使用的EJB分割开。建议适用Session Fa?ade模式。这个模式通过一个Session Bean，为一系列的EJB提供统一的接口来实现流程。事实上，当客户端只是使用这个接口来触发流程。这样，所有关于EJB实现流程所需要的改变，都和客户端无关。
看下面这个例子。这段代码用来控制与客户相关的订单的处理方法。
// All imports required
// Exception handling not shown in the sample code
public class OrderSessionFacade implements SessionBean {
// all EJB specific methods like ejbCreate defined here
// Here is the business method that does the workflow
// required when a customer places a new order
public int placeOrder(String customerId, Details orderDetails)
throws RemoteException {
// Get reference to the required EJBs
InitialContext ctxt = new InitialContext();
Object obj = ctxt.lookup("java:comp/env/ejb/UserAccount");
UserAccountHome acctHome = (UserAccountHome)
PortableRemoteObject.narrow(obj, UserAccountHome.class);
UserAccount acct = acctHome.create();
obj = ctxt.lookup("java:comp/env/ejb/CreditCheck");
CreditCheckHome creditCheckHome = (CreditCheckHome)
PortableRemoteObject.narrow(obj, CreditCheckHome.class);
CreditCheck credit = creditCheckHome.create();
obj = ctxt.lookup("java:comp/env/ejb/Approvals");
ApprovalsHome apprHome = (ApprovalsHome)
PortableRemoteObject.narrow(obj, ApprovalsHome.class);
Approvals appr = apprHome.create();
obj = ctxt.lookup("java:comp/env/ejb/CommitOrder");
CommitOrderHome orderHome = (CommitOrderHome)
PortableRemoteObject.narrow(obj, CommitOrderHome.class);
CommitOrder order = orderHome.create();
// Now do the required workflow to place the order
int result = acct.checkStatus(customerId);
if(result != OK) {
// stop further steps
}
result = credit.checkCreditWorth(customerId, currentOrder);
if(result != OK) {
// stop further steps
}
result = appr.getApprovals(customerId, currentOrder);
if(result != OK) {
// stop further steps
}
// Everything OK; place the order
int orderId = order.placeOrder(customerId, currentOrder);
// Do other processing required
return(orderId);
}
// Implement other workflows for other order related functionalities (like
// updating an existing order, canceling an existing order etc.) in a
// similar way
}
在模式允许的情况下，Servlet代码将很容易实现。
// all required imports
// exceptions to be caught appropriately wherever applicable
public class OrderHandlingServlet extends HttpServlet {
// all required declarations, definitions
public void init() {
// all inits required done here
}
public void doPost(HttpServletRequest request, HttpServletResponse response)
throws IOException, ServletException {
// other logic as required
// Get reference to the session facade
InitialContext ctxt = new InitialContext();
Object obj = ctxt.lookup("java:comp/env/ejb/OrderSessionFacade");
OrderSessionFacadeHome facadeHome = (OrderSessionFacadeHome)
PortableRemoteObject.narrow(obj, OrderSessionFacadeHome.class);
OrderSessionFacade facade = facadeHome.create();
// trigger the order workflow
int orderId = facade.placeOrder(customerId, currentOrder);
// do further processing as required
}
}
就象上面显示的，客户端的逻辑变得非常简单。流程中的任何改变只要修改模式中的一处地方就可以了。客户端可以仍旧使用原来的接口，而不必做任何修改。同样，这个模式可以用来响应其他处理器的流程处理。这让你能用同样的模式来处理不同客户端的不同流程。在这个例子中，模式提供了很好的伸缩性和可维护性。
c. 要点
§ 既然这种模式不涉及到数据访问，就应该用Session Bean来实现。
§ 对于用简单接口来实现复杂EJB的子系统来说，是一个理想的选择。
§ 这个模式不适用于无流程处理的应用。
§ 这个模式可以减少客户端于EJB之间的通信和依赖。
§ 所有和EJB有关的交互，都有同一个Session Bean来控制，可以减少客户端对EJB的误用。
§ 这个模式可以使支持多类型客户端变得更容易。
§ 可以减少网络数据传递。
§ 所有的服务器端的实现细节都对客户端隐藏，在改变发生后，客户端不用重新发布。
§ 这个模式可以同样看成一个集中处理器来处理所有的安全或日志纪录。
4. Data Access Object
a. 问题
目前为止，你看到的模型都是用来构建可伸缩的，易于维护的J2EE应用。这些模式尽可能的把应用在多个层上来实现。但是，还有一点必须强调：EJB的数据表现。它们包括象EJB这样的数据库语言。如果数据库有改变的话，相应的SQL也必须改变，而EJB也必须随之更新。
这些常见问题就是：访问数据源的代码与EJB结合在一起，这样致使代码很难维护。看以下的代码。
An EJB that has SQL code embedded in it
// all imports required
// exceptions not handled in the sample code
public class UserAccountEJB implements EntityBean {
// All EJB methods like ejbCreate, ejbRemove go here
// Business methods start here
public UserDetails getUserDetails(String userId) {
// A simple query for this example
String query = "SELECT id, name, phone FROM userdetails WHERE name = " + userId;
InitialContext ic = new InitialContext();
datasource = (DataSource)ic.lookup("java:comp/env/jdbc/DataSource");
Connection dbConnection = datasource.getConnection();
Statement stmt = dbConnection.createStatement();
ResultSet result = stmt.executeQuery(queryStr);
// other processing like creation of UserDetails object
result.close();
stmt.close();
dbConnection.close();
return(details);
}
}
b. 建议的解决方法
为了解决这个问题，从而让你能很方便的修改你的数据访问。建议使用DAO模式。这个模式把数据访问逻辑从EJB中拿出来放入独立的接口中。结果是EJB保留自己的业务逻辑方法，在需要数据的时候，通过DAO来访问数据库。这样的模式，在要求修改数据访问的时候，只要更新DAO的对象就可以了。看以下的代码。
A Data Access Object that encapsulates all data resource access code
// All required imports
// Exception handling code not listed below for simplicity
public class UserAccountDAO {
private transient Connection dbConnection = null;
public UserAccountDAO() {}
public UserDetails getUserDetails(String userId) {
// A simple query for this example
String query = "SELECT id, name, phone FROM userdetails WHERE name = " + userId;
InitialContext ic = new InitialContext();
datasource = (DataSource)ic.lookup("java:comp/env/jdbc/DataSource");
Connection dbConnection = datasource.getConnection();
Statement stmt = dbConnection.createStatement();
ResultSet result = stmt.executeQuery(queryStr);
// other processing like creation of UserDetails object
result.close();
stmt.close();
dbConnection.close();
return(details);
}
// Other data access / modification methods pertaining to the UserAccountEJB
}
现在你有了一个DAO对象，利用这个对象你可以访问数据。再看以下的代码。
An EJB that uses a DAO
// all imports required
// exceptions not handled in the sample code
public class UserAccountEJB implements EntityBean {
// All EJB methods like ejbCreate, ejbRemove go here
// Business methods start here
public UserDetails getUserDetails(String userId) {
// other processing as required
UserAccountDAO dao = new UserAccountDAO();
UserDetails details = dao.getUserDetails(userId);
// other processing as required
return(details);
}
}
任何数据源的修改只要更新DAO就可以解决了。另外，为了支持应用能够支持多个不同的数据源类型，你可以开发多个DAO来实现，并在EJB的发布环境中指定这些数据源类型。在一般情况下，EJB可以通过一个Factory对象来得到DAO。用这种方法实现的应用，可以很容易的改变它的数据源类型。
c. 要点
§ 这个模式分离了业务逻辑和数据访问逻辑。
§ 这种模式特别适用于BMP。过一段时间，这种方式同样可以移植到CMP中。
§ DAOs可以在发布的时候选择数据源类型。
§ DAOs增强了应用的可伸缩性，因为数据源改变变得很容易。
§ DAOs对数据访问没有任何限制，甚至可以访问XML数据。
§ 使用这个模式将导致增加一些额外的对象，并在一定程度上增加应用的复杂性。