5_JAVA设计模式第五课：Observer模式在J2EE中的实现.docxVIP

引言：设计模式是经验的文档化。它是对被用来在特定场景下解决一般设计问题的类和相互通信的对象的描述。更通俗的来说，它是一个问题/解决方案对。一旦我们掌握了设计模式，就等于拥有了一支强有力的专家队伍。它甚至能够使面向对象的新手利用前人的经验找出职责明确的类和对象，从而获得优雅的解决方案。由于设计模式也是重构的目标，如果在设计的初期适当地引入设计模式，可以减少重构的工作量。但是，我们也不能陷入模式的陷阱，为了使用模式而去套模式，那样会陷入形式主义。我们在使用模式的时候，一定要注意模式的意图（intent），而不要过多的去关注模式的实现细节，因为这些实现细节在特定情况下，可能会发生一些改变。不要顽固地认为设计模式一书中的类图或实现代码就代表了模式本身。下面，我们来讨论一下为什么要在分布式、多层系统中使用Observer模式。多层体系结构（multi-tier architecture）：三层体系结构是多层体系结构中最简单的一种，它一般包括：表示层(presentation)－窗口、报表- 业务逻辑层(business logic)－管理业务过程的任务和规则。它又可以细分为领域对象层（代表领域概念）和服务层（提供数据库交互、安全性、打印报表）。 存储层(storage)－持久化存储机制。如数据库服务器等。 图一：三层体系结构而Java 2平台企业版（J2EE）是一种利用Java 2平台来简化诸多与多级企业解决方案的开发、部署和管理相关的复杂问题的体系结构。它是开放的、基于标准的平台，用以开发、部署和管理N层结构、面向Web的，以服务器为中心的企业级应用。为了支持领域对象的复用，并且使领域对象的接口变更所带来的影响最小化。我们将领域层（模型）和表示层（视图）相分离。采用模型－视图模式的意义在于：支持聚合度更高的模型定义，使模型的定义可以集中在领域过程的定义，而不是图形界面上。 允许将模型和用户界面并行开发。 使用户界面的需求变化对领域层所造成的影响最小化。 允许建立与一个现有的领域层对象相连接的新视图，同时不影响领域层。 允许一个模型同时有多个视图，例如使用SVG和表格。 允许模型层独立于用户界面层执行。 而这恰恰与Observer模式的意图相吻合。因此我们有必要跨层来实现Observer模式。其实，在应用中更多的是采用MVC框架来架构整个企业应用的。在MVC框架中，Model和View之间存在着依赖关系，是Observer模式的典型应用。当然MVC框架还包括其它模式如Composite模式和Strategy模式。在J2EE平台中，我们可以把Web Tier（包括Jsp和servelet和JavaBean）看作是表示层，EJB Tier看作是领域层。而controller可能跨距Web Tier和 EJB Tier。在Java类库中采用Java.util.Observable类和Java.util.Observer接口来实现Observer模式，它们在单个的Java VM.中运行的很好，但如果想在EJB中使用它们就会有一些问题。这正如我们引言中提到的，模式的具体实现在特定情况下，可能会发生一些改变。值传递还是远程引用传递？值传递：在Java RMI中要求所有的参数和返回类型是JAVA的基本类型或实现Java.io.Serilizable的对象。串行化对象通过值传递（又名拷贝传递），而不是引用传递，这意味着在某一层中串行化对象的更新并不自动影响到其它的对象。远程引用传递：对于EJB对象而言，它由两个接口（home接口和remote接口）和一个类组成。容器会根据ejb规范来生成实现上面两个接口的类（我们分别称为xxxEJBHome对象和xxxEjbObject对象）。在较多的容器的实现方案中，xxxEJBHome对象使用了factory模式来创建xxxEjbObject对象；xxxEjbObject对象则采用proxy模式，作为xxxBean的代理类。在生成以上两个对象的同时，容器会从部署文件中读取关于安全、事务、持久性等服务并在xxxEjbObject对象和xxxEJBHome对象中添加以上服务的代码。而且xxxEJBHome对象和xxxEjbObject对象都是分布式对象，我们在此只讨论xxxEjbObject对象。所谓分布式对象，从本质上来讲，分为3个部分：object server、skeleton、stub。其中object server和skeleton位于服务器端，而stub位于客户端。Object server负责实现业务逻辑，skeleton负责marshal和unmarshal方法签名。图二：分布式对象显然，EJB的客户（调用EJB的对象）可以是任何对象，包括EJB和一般的Java类甚至是用任何语言写的corba客户端。从