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)中以达到共享。