科技行者

行者学院 转型私董会 科技行者专题报道 网红大战科技行者

知识库

知识库 安全导航

至顶网软件频道基础软件基于java技术的软件开发架构总结

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

  • 扫一扫
    分享文章到微信

  • 扫一扫
    关注官方公众号
    至顶头条

软件分层是必须做的。至于框架,不应该问用不用,而应该问用什么?要选用实践检验过的框架,毕竟实践是检验真理的唯一标准。

作者:JavaFeng 来源:CSDN 2008年2月8日

关键字: 软件开发架构 java

  • 评论
  • 分享微博
  • 分享邮件
 


 


  
 
在具体的实现中,表现层可为Struts/JSF等,业务层、访问层可为JavaBeanEJB等,资源层一般为数据库。
 
宏观上的层次就是这样,在具体现实中,有如下几种实现形式:

1 轻量级实现


 
表现层使用基于MVC的框架,比如StrutsJSF
业务层使用JavaBean(就是常说的Service

访问层使用JavaBean(就是常说的DAO
优点:
 
轻量级实现,简单明了
ü
缺点:
 
难以无法实现分布式应用
ü
 
以下功能必须通过编程实现ü
 
事务控制²
 
资源管理(包括组件的创建)²
 
线程安全问题²
 
安全性²

2 重量级J2EE实现

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


 

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

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


 

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

4 轻量级J2EE实现


 
访问层通过JavaBean调用ORM框架实现(HibernateiBatis等),代码简洁,功能完备(相对于EJB 2.x而言),如果用的是Hibernate,可以忽略底层数据库的差异,如果用的是iBatis,则方便对SQL进行优化。

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


 
另类之处:
 
使用BMP + Hibernate(具体做法为BMP中的持久化方法,比如ejbLoad, ejbStore等都委托给Hibernate实现)
优点:
 
借助于Hibernate强大的ORM功能弥补CMP的不足(特别是EJB-QL

缺点:
 
事物不好控制
 
不伦不类,容易发生未知的错误(比如Hibernate自身的缓存可能会于容易提供的缓存冲突)

 
另类之处:
 
将业务层(也可能包含访问层)包装成Web Services,支持远程调用
优点:
 
借助于Web Services可以实现松散耦合分布式应用,说的大一点,就是传说中的SOA,呵呵

缺点:
 Web Services
自身效率不高,无状态,安全性差

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

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


查看本文来源
    • 评论
    • 分享微博
    • 分享邮件
    邮件订阅

    如果您非常迫切的想了解IT领域最新产品与技术信息,那么订阅至顶网技术邮件将是您的最佳途径之一。

    重磅专题
    往期文章
    最新文章