基于java技术的软件开发架构总结

<shapetype id="_x0000_t75" stroked="f" filled="f" path="m@4@5l@4@11@9@11@9@5xe" o:preferrelative="t" o:spt="75" coordsize="21600,21600"><stroke joinstyle="miter"></stroke><formulas><f eqn="if lineDrawn pixelLineWidth 0"></f><f eqn="sum @0 1 0"></f><f eqn="sum 0 0 @1"></f><f eqn="prod @2 1 2"></f><f eqn="prod @3 21600 pixelWidth"></f><f eqn="prod @3 21600 pixelHeight"></f><f eqn="sum @0 0 1"></f><f eqn="prod @6 1 2"></f><f eqn="prod @7 21600 pixelWidth"></f><f eqn="sum @8 21600 0"></f><f eqn="prod @7 21600 pixelHeight"></f><f eqn="sum @10 21600 0"></f></formulas><path o:connecttype="rect" gradientshapeok="t" o:extrusionok="f"></path><lock aspectratio="t" v:ext="edit"></lock></shapetype><shape id="_x0000_i1025" style="WIDTH: 426pt; HEIGHT: 41.25pt" o:button="t" alt="" type="#_x0000_t75"><imagedata o:href="http://album.sina.com.cn/pic/4a5ca02402000h0b" src="file:///D:%5CDOCUME~1%5CADMINI~1%5CLOCALS~1%5CTemp%5Cmsohtml1%5C01%5Cclip_image001.gif"></imagedata></shape>
在具体的实现中，表现层可为Struts/JSF等，业务层、访问层可为JavaBean或EJB等，资源层一般为数据库。
宏观上的层次就是这样，在具体现实中，有如下几种实现形式：

1，轻量级实现

<shape id="_x0000_i1026" style="WIDTH: 536.25pt; HEIGHT: 106.5pt" o:button="t" alt="" type="#_x0000_t75"><imagedata o:href="http://album.sina.com.cn/pic/4a5ca02402000h0c" src="file:///D:%5CDOCUME~1%5CADMINI~1%5CLOCALS~1%5CTemp%5Cmsohtml1%5C01%5Cclip_image002.gif"></imagedata></shape>
表现层使用基于MVC的框架，比如Struts或JSF
业务层使用JavaBean（就是常说的Service）
访问层使用JavaBean（就是常说的DAO）
优点：
轻量级实现，简单明了ü
缺点：
难以无法实现分布式应用ü
以下功能必须通过编程实现ü
事务控制²
资源管理（包括组件的创建）²
线程安全问题²
安全性²

2，重量级J2EE实现

表现层依然是基于MVC的框架
访问层采用实体Bean实现，如果可能最好采用CMP，实现起来更简洁。此处的实体Bean可以考虑采用本地接口
业务层一分为二，服务控制器可以由会话Bean充当，用来封装业务流程（相当于轻量级实现中的Service），也可以考虑采用本地接口；门面也可以由会话Bean充当（一般来说无状态会话Bean足矣），作为业务层的入口，应该采用远程接口。
优点：
以下功能可由EJB容器自动实现，或通过配置实现ü
事务控制²
远程访问²
线程安全²
资源管理²
安全性²
可以进行分布式应用ü
因为采用了EJB，故部分特征可以由装配人员来配置（比如事务，安全性等），不需要在软件中硬编码ü
EJB组件有更好的重用性ü
可利用容器提供的其他企业级的功能（比如集群，容错，灾难恢复等）ü
可以加入MDB（实现异步通讯）等技术ü
缺点：
开发难度较高ü
如果不恰当的使用实体Bean，会造成效率低下。如果采用CMP，则很多数据访问的操作不能直接实现。ü
缺少良好的开发环境ü
软件可能依赖于具体的EJB容器ü
EJB容器可能很贵，开发软件也可能很贵ü

<shape id="_x0000_i1027" style="WIDTH: 536.25pt; HEIGHT: 106.5pt" o:button="t" alt="" type="#_x0000_t75"><imagedata o:href="http://album.sina.com.cn/pic/4a5ca02402000h0d" src="file:///D:%5CDOCUME~1%5CADMINI~1%5CLOCALS~1%5CTemp%5Cmsohtml1%5C01%5Cclip_image003.gif"></imagedata></shape>

3，轻量级和重量级J2EE的切换

如果项目有需求，并有充分的时间，还可以通过在表现层和业务层的交界处加入“业务代表”（JavaBean + 服务定位器实现）来对表现层隐藏对业务层访问的细节(JavaBean和EJB的访问方式显然不同)，只需替换“业务代表”就可以切换轻量级和重量级两种实现。举例说明，一般电话上都有一个P/T开关（脉冲/音频开关），随着开关状态的不同，拨号时电话机会判断是使用脉冲拨号还是音频拨号。

<shape id="_x0000_i1028" style="WIDTH: 584.25pt; HEIGHT: 221.25pt" o:button="t" alt="" type="#_x0000_t75"><imagedata o:href="http://album.sina.com.cn/pic/4a5ca02402000h0e" src="file:///D:%5CDOCUME~1%5CADMINI~1%5CLOCALS~1%5CTemp%5Cmsohtml1%5C01%5Cclip_image004.gif"></imagedata></shape>

这种架构唯一的缺点就是必须写两套实现代码……

4，轻量级J2EE实现

<shape id="_x0000_i1029" style="WIDTH: 536.25pt; HEIGHT: 175.5pt" o:button="t" alt="" type="#_x0000_t75"><font face="宋体"> <imagedata o:href="http://album.sina.com.cn/pic/4a5ca02402000h0f" src="file:///D:%5CDOCUME~1%5CADMINI~1%5CLOCALS~1%5CTemp%5Cmsohtml1%5C01%5Cclip_image005.gif"></imagedata></font></shape>
访问层通过JavaBean调用ORM框架实现（Hibernate，iBatis等），代码简洁，功能完备（相对于EJB 2.x而言），如果用的是Hibernate，可以忽略底层数据库的差异，如果用的是iBatis，则方便对SQL进行优化。

业务层和访问层依靠AOP框架（如Spring）可以在切面中实现事务，安全性等功能，同时不影响业务代码。如果采用Spring，其中已经内置了事物切面，并可以轻易的与主流ORM框架进行整合，实现声明式的事物管理。当然，更可以使用IoC模式降低组件间的耦合性。
优点：
可以通过AOP框架实现事物、安全性等功能，同时不影响业务代码²
ORM框架比CMP更灵活，比BMP更简洁（相对于EJB² 2.x而言），运行效率也比较高
如果使用Spring，可以用更简单的方式实现J2EE中比较复杂的功能²
无需额外的容器²
ORM和AOP框架可以找到免费的开源实现，降低项目成本（不过也有人认为采用开源项目可能综合成本更高）²
缺点：
非官方框架，缺少文档、技术支持和业界经验²
采用技术太多，学习曲线较高，难以招到合适的程序员（咱们学员可以考虑在这方面下点功夫，呵呵）²
某些企业级的功能轻量级框架还不能实现（或独立实现）²-----------------------------------------
测试、调试均比较复杂²

<shape id="_x0000_i1030" style="WIDTH: 536.25pt; HEIGHT: 174pt" o:button="t" alt="" type="#_x0000_t75"><imagedata o:href="http://album.sina.com.cn/pic/4a5ca02402000h0g" src="file:///D:%5CDOCUME~1%5CADMINI~1%5CLOCALS~1%5CTemp%5Cmsohtml1%5C01%5Cclip_image006.gif"></imagedata></shape>
另类之处：
使用BMP + Hibernate（具体做法为BMP中的持久化方法，比如ejbLoad, ejbStore等都委托给Hibernate实现）
优点：
借助于Hibernate强大的ORM功能弥补CMP的不足（特别是EJB-QL）
缺点：
事物不好控制
不伦不类，容易发生未知的错误（比如Hibernate自身的缓存可能会于容易提供的缓存冲突）

<shape id="_x0000_i1031" style="WIDTH: 536.25pt; HEIGHT: 173.25pt" o:button="t" alt="" type="#_x0000_t75"><imagedata o:href="http://album.sina.com.cn/pic/4a5ca02402000h0h" src="file:///D:%5CDOCUME~1%5CADMINI~1%5CLOCALS~1%5CTemp%5Cmsohtml1%5C01%5Cclip_image007.gif"></imagedata></shape>
另类之处：
将业务层（也可能包含访问层）包装成Web Services，支持远程调用
优点：
借助于Web Services可以实现松散耦合分布式应用，说的大一点，就是传说中的SOA，呵呵
缺点：
Web Services自身效率不高，无状态，安全性差

　　当然，即使不分层，也能做出软件来，但我们应该思考怎么做才能最好？如果说分层不好，那么不分层的优势又在哪里呢？？如果说分层有性能的损耗，那么性能损耗在哪里呢？？如果不分层，软件工程思想中的“分而治之”的原则启不受到了质疑？
有人说，分层是为了减少代码量，如果分层是为了减少代码量，那怎么能减少，代码的重用也许会减少一些，但是程序更多的是业务，我们关心的也只是业务，试问分层的意义就是为了减少代码量？
总之我的观点就是：软件分层是必须做的。至于框架，不应该问用不用，而应该问用什么？要选用实践检验过的框架，毕竟实践是检验真理的唯一标准。

二年的J2EE开发之后，我们应该掌握了一些主流的架构模式，总结一下：
宏观上讲，我们采用了分层的架构，将软件分为如下的层次：