对数据源的抽象操作行为.
提供了非常方便访问和维护管理数据的API结构.
DAOImplementor (CatalogDAOImpl 有可能有CatalogDAOImplSybase CatalogDAOImplMysql 等) 实现具体的DAO接口内容.
使用Adapter模式，将特定的数据源驱动接口适配到DAO接口中去
数据源 ( Oracle, or Sybase database via JDBC API) 提供访问具体数据库的驱动接口，如包括连接池等. 在使用数据源驱动接口时，需要使用Adapter模式，Adapter模式将两个不相关的类纠合在一起使用，Adapter模式实际是使用组合(composition)和继承(inheritance)两种方式再生类，在著名的"think in Java"的"类再生"专门提到这两个方式. 很显然，如果你对Bridge模式和Adapter模式熟悉，那么对宠物店中的Catalog理解就会非常快，同样，在宠物店其他部分如订单 用户注册 等都能迅速理解。 Factory模式和Singleton模式
该模式类似new，是用来创建对象的，使用Factory模式是为了实现面向对象的基本原则.封装(Encapsulation)和分派(Delegation);将创建对象与使用对象进行分工。因此在平时开发过程中，尽量使用Factory模式创建对象。 本例CatalogEJB中是使用Factory模式获得一个DAO的具体实例对象，见上面CatalogEJB代码中注释。我们看看CatalogDAOFactory的代码: public class CatalogDAOFactory {
public static CatalogDAO getDAO() throws CatalogDAOSysException { CatalogDAO catDao = null;
try {
InitialContext ic = new InitialContext();
String className = (String) ic.lookup(JNDINames.CATALOG_DAO_CLASS);
catDao = (CatalogDAO) Class.forName(className).newInstance();
} catch (NamingException ne) {
... }
return catDao;
} |
在CatalogDAOFactory可以依据系统的配置文件，动态获得DAO的方法，之所以采取动态方式，当然便于用户自己增加自己的DAO方式，而不必修改代码，只要直接修改配置文件就可以。 如果在这里只需要CatalogDAOFactory产生一个实例,可以采取Singleton模式,Singleton的目的是控制类实例对象的创建，并且允许整个程序只在一点对它进行访问。Singleton本身类只能创建一个,是单线程。 public class CatalogDAOFactory {
private static CatalogDAO catDao = null; public static CatalogDAO getIntance(){
if (catDao==null)
try {
InitialContext ic = new InitialContext();
String className =
(String) ic.lookup(JNDINames.CATALOG_DAO_CLASS);
catDao = (CatalogDAO) Class.forName(className).newInstance();
} catch (NamingException ne) {
... }
}
return catDao; }
} |
那么在CatalogEJB的调用从
dao = CatalogDAOFactory.getDAO();
要改为
dao = CatalogDAOFactory.getIntance(); Facade模式
在EJB应用中，有两个端点，这一端是用户端，另外一端是EJB,通常在这两个端点间会增加一层，用来松散两个端点之间的耦合，比如在宠物店例子中,考虑到不同身份的用户有不同的操作流程，比如顾客注册进入后，需要浏览目录，下订单，而商店管理者进入后需要确认或者否定订单，或者检查库存。这些功能需要借助Session bean和Entity bean完成。 但是如果用户端直接和这些bean互动,会有以下问题: 1. 用户端必须注意和这些beans的所有有联系或互动的事情，无法阻止用户端可能不恰当的使用这些beans.
2.如果EJB的API改动，那么用户端的一些代码也要修改。无疑扩展性很差。
3.即使这些beans都在同一台服务器上，用户端还是用remote方式来调用它们，造成网络无故拥挤。 那么我们使用Facade模式来解决这个问题，Facade的定义是为子系统中的一组接口提供一个一致的界面,很显然我们需要为这些bean提供一个统一的对外界面。如下图： 
在宠物店中，ShoppingClientFacadeLocalEJB是面对所有用户端操作的统一界面，用户端操作就不直接和那些EJB如CustomerEJB或ShoppingCartEJB有联系,而是都通过ShoppingClientFacadeLocalEJB来联系的。代码如下： public class ShoppingClientFacadeLocalEJB implements SessionBean {
... //和CustomerEJB联系
public CustomerLocal getCustomer() throws FinderException {
if (userId == null) {
...
}
try {
InitialContext ic = new InitialContext();
Object o = ic.lookup("java:comp/env/ejb/petstore/local/customer");
CustomerLocalHome home =(CustomerLocalHome)o;
customer = home.findByPrimaryKey(userId);
} catch (javax.naming.NamingException nx) {
...
} return customer;
} ..... //和ShoppingCartEJB联系
public ShoppingCartLocal getShoppingCart() {
if (cart == null) {
try {
InitialContext ic = new InitialContext();
Object o = ic.lookup("java:comp/env/ejb/cart/Cart");
ShoppingCartLocalHome home =(ShoppingCartLocalHome)o;
cart = home.create();
} catch (javax.ejb.CreateException cx) {
...
}
}
return cart;
} .... } |
Facade模式参与者： SessionFacade (ShoppingClientFacadeLocalEJB) 提供一组操作流程
将真正工作委托到EJB的bean.
EJB的bean (CustomerEJB, ShoppingCartEJB等等) 执行基本的商业逻辑操作
没有任何对SessionFacade的调用. 这样不但可扩展性大大增强，效率也提高了，用户端只需要一次Remote对SessionFacade调用就可以了，而SessionFacade会自动定位到与它同一台服务器的那些邻居bean(CustomerEJB, ShoppingCartEJB等等),无疑减少网络拥挤，提高了速度. 总结
在EJB的具体使用中，使用合适的设计模式，不但使代码可重用性 可拓展性增强，最重要的是能提高效率和速度，我们知道EJB框架由于考虑大型系统中事务安全等各方面问题，效率性能有所欠缺，那么我们在具体问题具体应用时，使用设计模式可以弥补这个问题。 例如Proxy模式可以为我们在访问巨大的需要花费一定时间才能展开的对象时，提供一个代理，这样不会因为那个巨大对象而影响当前运行速度，EJB中的那些bean很显然属于巨大对象（因为它们有反复的数据库操作，这些很费时间〕。 Flyweight模式是避免大量拥有相同内容的小类的开销(如耗费内存),使大家共享一个类(元类).当你要从EJB中获取一系列字符串,而这些字符串中肯定有许多是重复的,那么我们可以将这些重复的字符串储存在Flyweight池(pool)中以达到共享。 在以后篇幅中会陆续介绍此类应用。
说明：本教程来源互联网或网友上传或出版商，仅为学习研究或媒体推广，wanshiok.com不保证资料的完整性。
2/2 首页 上一页 1 2 |
