前台控制l出了一个基于MVC的，能有效管理用户与J2EE应用之间q行的复杂交互。这个模式可以处理面的现实顺序和用户的ƈ发请求变得简单。ƈ且增加和改变页面现实变得更加容易?BR>
另外一个常见的问题是，当EJB或者业务逻辑发生变化的时候，应用的客L也必随之改变。我们来看一下这个问题?BR>
一般来_Z表现一个̎户中的用P我们使用一个业务逻辑来表C̎户中的信息，象用户名和口令，再用一个EJB来管理用L个h信息Q象爱好Q语a{。当要创Z个新的̎h者修改一个已l存在的账号Ӟ必须讉K包含账号信息的EJBQ读取个Z息，修改q且保存Q这L一个流E?BR>
当然Q这只是一个非常简单的例子Q实际情况可能比q个复杂的多Q象查看用户定制了哪些服务，验客户信用卡的有效性，存放订单{。在q个案例中，Z实现一个完整的程Q客L必须讉K账户EJB来完成一pd适当的工作。下面的例子昄了一个Servlet客户端如何来控制一个用戯单?BR>
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
}
}
以上的代码显CZ一个单个的客户端。如果这个应用支持多U客L的话Q必Mؓ每一个客L制定一U处理方法来完成工作程。如果有一个EJB的实现流E需要改变的话，那么所有的参与q个程的客L都需要改变。如果不同的EJB之间的交互需要改变的话，所有的客户端都必须知道q一点，如果程中需要增加一个新的步骤的话，所有的客户端也必须随之修改?
q样一来，EJB和客L之间的改变变得非常困难。客L必须Ҏ个EJB分开q行讉KQ致使网l速度变慢。同P应用复杂，ȝ大?/P>
b. 的解x?BR>
解决q个问题的方法是Q把客户端和他们使用的EJB分割开。徏议适用Session Fa?ade模式。这个模式通过一个Session BeanQؓ一pd的EJB提供l一的接口来实现程。事实上Q当客户端只是用这个接口来触发程。这P所有关于EJB实现程所需要的改变Q都和客L无关?BR>
看下面这个例子。这D代码用来控制与客户相关的订单的处理Ҏ?BR>
// 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代码很Ҏ实现?BR>
// 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
}
}
p上面昄的，客户端的逻辑变得非常单。流E中的Q何改变只要修Ҏ式中的一处地方就可以了。客L可以仍旧使用原来的接口，而不必做M修改。同Pq个模式可以用来响应其他处理器的程处理。这让你能用同样的模式来处理不同客户端的不同程。在q个例子中，模式提供了很好的伸羃性和可维护性?BR>c. 要点
既然q种模式不涉及到数据讉KQ就应该用Session Bean来实现?BR>
对于用简单接口来实现复杂EJB的子pȝ来说Q是一个理想的选择?BR>
q个模式不适用于无程处理的应用?BR>
q个模式可以减少客户端于EJB之间的通信和依赖?BR>
所有和EJB有关的交互，都有同一个Session Bean来控Ӟ可以减少客户端对EJB的误用?BR>
q个模式可以使支持多cd客户端变得更Ҏ?BR>
可以减少|络数据传递?BR>
所有的服务器端的实现细节都对客L隐藏Q在改变发生后，客户端不用重新发布?BR>
q个模式可以同样看成一个集中处理器来处理所有的安全或日志纪录?BR>
4. Data Access Object
a. 问题
目前为止Q你看到的模型都是用来构建可伸羃的，易于l护的J2EE应用。这些模式尽可能的把应用在多个层上来实现。但是，q有一点必d调：EJB的数据表现。它们包括象EJBq样的数据库语言。如果数据库有改变的话，相应的SQL也必L变，而EJB也必随之更新?BR>
q些常见问题是Q访问数据源的代码与EJBl合在一Pq样致代码很难l护。看以下的代码?BR>
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. 的解x?BR>
Z解决q个问题Q从而让你能很方便的修改你的数据讉K。徏议用DAO模式。这个模式把数据讉K逻辑从EJB中拿出来攑օ独立的接口中。结果是EJB保留自己的业务逻辑ҎQ在需要数据的时候，通过DAO来访问数据库。这L模式Q在要求修改数据讉K的时候，只要更新DAO的对象就可以了。看以下的代码?BR>
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对象Q利用这个对象你可以讉K数据。再看以下的代码?BR>
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);
}
}
M数据源的修改只要更新DAO可以解决了。另外，Z支持应用能够支持多个不同的数据源cdQ你可以开发多个DAO来实玎ͼq在EJB的发布环境中指定q些数据源类型。在一般情况下QEJB可以通过一个Factory对象来得到DAO。用q种Ҏ实现的应用，可以很容易的改变它的数据源类型?BR>
c. 要点
q个模式分离了业务逻辑和数据访问逻辑?BR>
q种模式特别适用于BMP。过一D|_q种方式同样可以UL到CMP中?BR>
DAOs可以在发布的时候选择数据源类型?BR>
DAOs增强了应用的可~性，因ؓ数据源改变变得很Ҏ?BR>
DAOsҎ据访问没有Q何限Ӟ甚至可以讉KXML数据?BR>
使用q个模式导致增加一些额外的对象Qƈ在一定程度上增加应用的复杂性?BR>
]]>
MVCl出了一个整个应用的松散的耦合架构。现在来看一下这样一个经常发生的情况。在某一个应用中Q用L到的视图和他所做的操作密切相关。这是一些具有高度交互性的面Q而这些页面之间含有高度的依赖性。在没有M模式的时候，q个应用只是一个许多独立的面的集合，l护和扩展变得异常困难?BR>
当一个页面移动后Q其他含有这个页面链接的文gQ都必须修改?BR>
当有一pd面需要口令保护时Q许多配|文仉要修改，或者页面需要包含新的标记?BR>
当一个页面需要一个新的表C层Ӟ面中的标记要被重新安排?BR>
当这个系l变得复杂时Q这些问题将变得更糟。如果用MVC来解决的话，变成一个如何管理控制器和视图之间交互的问题?BR>
b. 的解x?BR>
前台控制模式可以解决q个问题。这个模式中Q所有的h都被传送到一个对象中。这个主要的对象处理所有的hQ决定以后显C那一个视图，以及实现必要的安全需求。对于把视图昄以及其他功能实现集中C个主要的对象中，修改变得很容易，对应用的修改Q可以在所有视图中反映出来?BR>
c. 要点
q个模式对于需要在多个含有动态数据的面之间q行复杂D的系l来_是很有效的?BR>
q个模式对于要在所有页面中都包含模板，转换{的应用来说Q也是很有效的?BR>
׃视图的选择集中在前端控制器上，因此Q视囄D变得更加Ҏ理解和便于配|?BR>
视图重用和变更会更加Ҏ?BR>
视图之间的复杂交互，使得控制器变得复杂。从而，当应用发展的时候，控制器将变得难以l护。不q，大部分情况下可以用XML映射来解冟?BR>
实现应用要求的安全性检验变得很单?BR>
q个模式不适合型的，只显C静态内容的应用?BR>
d. 样例
RequestMappings.xml 文g映射了传入的hQ处理器以及下一个页面?BR>
useRequestHandler="true"
requiresSecurityCheck="true" nextScreen="screen2.jsp">
com.blah1.blah2.blah3.request1Handler
以上q个文g是控制器的指定配|，控制器的代码如下Q?BR>
FrontControllerImpl.java 利用上面的XML实现了控制器
// all required imports
// exceptions to be caught appropriately wherever applicable
public class FrontControllerImpl extends HttpServlet {
// all required declarations, definitions
private HashMap requestMappings;
public void init() {
// load the mappings from XML file into the hashmap
}
public void doPost(HttpServletRequest request,
HttpServletResponse response)
throws IOException, ServletException
{
doGet(request, response);
}
public void doGet(HttpServletRequest request, HttpServletResponse response)
throws IOException, ServletException {
String currentPage= request.getPathInfo();
// get all mapping info for "currentPage" from the hashmap
// if "securityCheckRequired = true", do the security check
// if "useRequestHandler = true", pass on the incoming request to the specified handler
// forward the results to the given "nextScreen"
}
}
用这U方法实现的控制器将很容易维护，当应用有新的变动的时候，只要修改XML文gp解决了。前台控制模式将使在视图和控制器之前有复杂交互的J2EE应用变得单?img src ="http://www.aygfsteel.com/giftedjacky/aggbug/831.html" width = "1" height = "1" />
]]>
如果开发一个企业应用Q只需要一U客L的话Q那么一切都非常Ҏ解决。但真实情况是，我们必须面对q行在各U设备上客户端，象PDAQWAP览器以及运行在桌面上的览器，我们不得不开发不同的应用E序来处理来自不同客L的请求。数据访问与现实淆在一P可能会出现重复的数据讉KQ导致整个开发周期没有必要的廉?BR>
b. 的解x?BR>
Model-View-Controller (MVC) 开发模式被证明是有效的处理Ҏ之一。它可以分离数据讉K和数据表现。你可以开发一个有伸羃性的Q便于扩展的控制器，来维护整个流E。如?所CZؓ整个模式的结构。MVC模式可以被映到多层企业U的J2EE应用上?BR>
所有的企业数据以及商业逻辑可以作ؓ模式?BR>
视图可以通过模式讉K数据QƈҎ客户端的要求来显C数据。视囑ֿM证当模式改变的时候，数据昄也必d时改变?BR>
控制器用来结合模式和视图Q把客户端来的请求{换成模式能够理解q执行的hQƈ且根据请求以及执行结果来军_下一ơ显C那一个视图?BR>
Ҏ以上的逻辑Q你可以象这样徏立一个应用：
应用的商业逻辑由MVC中的模式也就是EJB来表现。模式必d理由控制器传递过来的Ҏ据的讉Kh?BR>
多个面l成了MVC中的视图Q这些视囑ֿ随模式一h新?BR>
控制器是一pd接收用户动作的对象，他们把用Lh转换成模式可理解的请求，q决定显C那一个页面当模式处理完请求后?BR>
c. 要点
MVCl构适用于那些多用户的，可扩展的Q可l护的，h很高交互性的pȝ?BR>
MVC可以很好的表辄L交互和系l模式?BR>
很方便的用多个视图来昄多套数据Q是pȝ很方便的支持其他新的客户端类型?BR>
代码重复辑ֈ最低?BR>
׃分离了模式中的流控制和数据表玎ͼ可以分清开发者的责QQ另外，也可以加快品推向市场的旉?img src ="http://www.aygfsteel.com/giftedjacky/aggbug/830.html" width = "1" height = "1" />
]]>