spring下的J2EE架构模式

               一 前言

  1.1 spring的神奇出现
                springframework的流行原因是它填补了J2ee开发架构的一个轻量级基于pojo的空缺，让应用开发回到keep it simple的怀抱。如果说人们为什么这么喜欢springframework，那得从j2ee的ejb规范是何等的复杂，前端的servlet/jsp是多么的惨白，而不使用ejb开发又遭人鄙视，视为技术的落后来说起。那个时候是没有大师出来说话的时代，谁也无法对J2EE规范的说不合理，没有几个人真正的明白持久化、MVC、分布式部署、事务管理的真正含义，既然不懂，而整个业界、IT中间件容器提供商、客户都在要求使用最“先进”的技术，也就是ejb。一旦涉足于这个区域，代码变现的主要时间则花费在了配置文件的编写上。开发、部署一个ejb让人望而止步，servlet/jsp遵循了kiss的原则，但并没有明确的指明MVC，以及如何和business logic分离。总之，本来一切都可以简单，一切都基于接口即可，分布式计算的不良设计已经得到事实的证明，我在2004年开始进入IT领域，正处在EJB凋零，POJO回归的年代，作为一个小小的JAVA开发者，并不懂哪些技术是好，哪些技术不好，窥视J2EE ejb的部署、规范，好不容易折腾了一天部署好，却发现它是那么的臃肿与强侵入性，大量的远程异常捕获代码、接口方法等强加于业务逻辑代码之上，非常讨厌。

               dependence injection: spring的神奇之处就是dependence injection依赖注入，基于get/set、construction等方式组装bean对象，将一个热乎乎的可用的实例送到你的手中，DI是spring的根基，而仅仅有这个根基顶多是当做huge factory pattern来使用(巨大的工厂模式)，在based on interface的原则下实现基于配置的product可插拨。而真正富于现实意义的spring是一大堆的模板、代理、链(spring的底层无处不是GOF的设计模式)。所谓开箱即用的组件，spring persistence template、spring security、spring jms、spring service，他们是对原J2EE规范中的众多底层代码的封装，让开发人员更加集中business logic develop。需要强调的是spring并没有试图取代ejb，或者说灭绝J2EE容器，它发展出了一套自己的架构模式来分离底层代码与业务逻辑代码，当然，真正清理得干干静静的是实体bean。

              aspect of program:面向方面的编程出现得由来已久。回忆下面向过程、面向对象的编程方式，其实二者都是命令过程式编程方式，只是思想不同而已，程序的结构都是heap area、stack area，在heap中分配内存，并写入自己的数据，而对于这些数据，你可以看成对象（面向对象），也可以看成struct结构体（面向过程）。面向过程的分析设计方法基于功能、任务来实现，通过分层、分模块来分配职能给各个代码文件（在面向对象中看成类），并导入这些文件，使用其中的函数、方法。面向对象的思想在于真正的在代码中映射现实世界，每个代码文件称为class，让他来代表一个现实世界的一个领域，并赋予其属性、行为，组织他们之间的关系。据我所知，尽管大家反复强调面向对象，实际上大家一点也不面向对象，只是简单的使用没有行为的领域对象而已，他们的关系、行为还是封锁在面向过程世界里。当然，面向对象的继承、多态、封装三大特性以一种预见性的方式为开发人员提供代码的可复用性（很想知道c是怎样基于接口编程的）。不管怎样，面向过程是靠近机器指令结构的，而面向对象是靠编译器将这种对象思想转变成纯过程。说了这么多，我总结陈词，面向对象根本就没有取代过面向过程，而是在各大编译器的支持下引入了一种思想，同样，AOP面向过程式的编程也是一种思想，而且是比较前两者简单的思想，它并不是取代面向对象，而是增强其最大化的可复用性。分离日志、审计、安全、底层事物等代码，实现业务逻辑代码的全解耦。aop相对还算是一个新东西，因此它没有编译器的支持，只能给予字节码或者代理的方式将代码插入到业务逻辑中。
           spring中有几个AOP专业术语，必须弄清楚，否则刚刚接触的人会头晕目眩。advise,中文翻译是“建议”，你可以想象一个人指着你的代码说，“我想在这里给点advise”，好了，advise就是非业务逻辑代码，但必须需和业务逻辑搅和在一起的东西。同学，请注意我前面使用的“这里”，在spring中称为cutpoint，横切点。最后在来找这些横切点，并放入这些建议呢？advisor，由一个顾问来做。你会看到aop的配置文件中到处是advisor、advise、cutpoint。

         1.2 粗粒度的应用部署架构

                          要谈J2EE架构，要从外而内，做逻辑部署结构到代码分层设计，再到领域对象设计。下面是我们公司应用的普遍性物理部署架构图。

 

 

        三层结构，client、web、app，只有app可以访问数据库。web、app之间通过ejb来互相调用，app和app之间也是通过ejb调用。在外部合作伙伴区，有可能使用web service的调用方式。当然，企业内部还有sso、ldap、esb等其他公用模块的介入，在这里并没有加进来。

 

         1.3细粒度代码结构

          在逻辑结构上将代码分层（面向过程的思考方法）是spring j2EE架构的普通做法，最前面是MVC（模型、控制器、视图），可以用一个delegate object来访问APP，APP是以session bean作为facade模式（my company call it as pafaAC，maybe application controller），它封装了尽可能多的业务方法，为了保证POJO，并与EJB解耦，在session facade后面引入service层，由他来调用真正的业务逻辑，以及DAO（data access object）。好了，就这么简单。为了解耦定义了主要的两层接口service lay interface、persistence lay interface。service层可以放在ejb中用，也可以直接被前段的controller用。而persistence则是为了适应不同的ORM或者直接使用jdbc。

                我们将一个J2EE应用分三层：

                 表示层：也就是web服务器，主要运用MVC

                 业务层：集中书写业务逻辑代码的地方

                 集成层：包括对数据库的访问、异步调用、webservcie异构等等。