BlogJava-大音希声、大象无形-随笔分类-综述http://www.blogjava.net/guitarpoet/category/8703.htmlJava企业级应用软件开发探讨zh-cnFri, 02 Mar 2007 03:36:30 GMTFri, 02 Mar 2007 03:36:30 GMT60AOP能干什么？http://www.blogjava.net/guitarpoet/archive/2006/03/27/37653.htmlguitarpoetguitarpoetMon, 27 Mar 2006 09:46:00 GMThttp://www.blogjava.net/guitarpoet/archive/2006/03/27/37653.htmlhttp://www.blogjava.net/guitarpoet/comments/37653.htmlhttp://www.blogjava.net/guitarpoet/archive/2006/03/27/37653.html#Feedback0http://www.blogjava.net/guitarpoet/comments/commentRss/37653.htmlhttp://www.blogjava.net/guitarpoet/services/trackbacks/37653.html
AOP是Aspect Oriented Programming的缩写，翻译成中文就是面向方面编程。它是最近几年流行起来的另一种编程方式。

  • 首先，AOP只是OOP的补充，换句话说，Procedure Oriented Programming的工程是很难，也是几乎不可能使用AOP的。
  • 其次，AOP是对OOP系统的纵向切割，从另一个方面上实现了系统解耦
  • 再次，AOP给OOP提供了另一种重用的可能。

对于OOP系统而言，系统的解耦主要依赖分层和良好的设计，一般良好的OOP架构没有不采用分层和设计模式的（当然，分层分得恰当不恰当、模式用得好不好，跟框架的设计者有着直接的关系）。但是，对于OOP系统而言，它只能到达这一步了。

对于系统的必须要求，比如日志、错误跟踪、访问拦截、权限控制等操作，OOP就很难达到八面玲珑。

其实，倒不是OOP一定不能实现上述功能的分离和重用，但是由于那又需要更高层次的抽象和封装，凭空增加系统的复杂性和使用难度，又不利于版本控制和发布控制，一般来说，是得不偿失的。

所以，很多开源项目比如Commons Logging等应运而生，它们的存在从一定的意义上解决了这个问题。

但是，还有一种很好的解决方案，那就是AOP（实际上AOP就是为了解决这种问题而诞生的）。

AOP既然是OOP系统的纵向切割，那么它就应该具备以下几点：

  1. 切入点（Point Cut）：它需要一个点来切入到OOP系统中去，目前流行的AOP框架都采用从方法切入的方式。
  2. 切面（Advice）：切入之后，它要做些什么呢？必须可以有一种方式进行定制，目前流行的AOP框架都采用Java代码实现的方式
  3. 重用性：一般来说，AOP能带来的重用一般都是Advice描述文件的重用，目前所有的AOP的Advice都是Java的Class文件，这就提供了一种可能，所有的Advice都可以通过打包成Jar的形式实现重用。

由此可以看出，使用AOP能够带来的好处是提供了一种抽象模型的方式、一种重用以前工作的方式（在不更改过去的代码的基础上添加新的功能、同时也可以重用过去写的Advice）。

AOP还有一个好处，就是减少工作量。

因为目前流行的AOP框架的PointCut定义一般都支持通配，这样就可以实现批量定义和修改。如果代码有着良好的规范、在良好的设计下，开发和维护工作量的减少会非常可观。而且对于添加新的功能不必修改原有的架构设计，从另一方面也降低了非常可观的工作量。

那么AOP在JavaEE企业级应用中能够起什么作用呢？

  1. 事务控制：很多业务逻辑方法都需要事务控制，通过通配实现事务控制绝对是一个节省工作量的好办法，如果再结合IOC更加可以脱离事务控制的依赖，实现事务控制灵活更换，提高了业务系统的重用性
  2. 权限控制：权限控制到底算不算业务逻辑？如果不算，为什么还要体现在业务逻辑中？通过AOP的方式，可以灵活的实现FilterChain机制，而业务逻辑的代码可以对其毫无察觉。
  3. 持久层对象的装饰和过滤：可以根据需要对持久层操作返回的结果进行装饰和过滤，甚至替换，而对系统架构没有任何要求。这是最漂亮和最干净的做法。
  4. 系统级别诊断日志：实现可插拔式系统级别日志，这样在系统正常运行后就可以为了提高系统性能而不费事的去掉它却不会影响到系统的稳定。
  5. 业务级别高级抽象：比如可以把工作流支持API封装，通过AOP的机制实现Mixin，这样就可以实现工作流支持和原业务逻辑分离，可以分开进行管理，也可以在更高的抽象级别上实现重用。

AOP也不是没有缺点，它本身就有一定的学习曲线，而且目前为止有具体意愿的好的实践并不多，而且它也会给你的工程带来复杂性，它还会给你的代码增加理解的难度（不管你承认不承认，代码阅读的难度确实是跟代码的耦合程度反相关的——虽然这是设计模式所力图解决的问题）

但是，目前来看适当的使用AOP，给你的项目提高灵活性和可维护性，是值得的。

guitarpoet 2006-03-27 17:46 发表评论
]]>容器和轻量级容器http://www.blogjava.net/guitarpoet/archive/2006/03/24/37180.htmlguitarpoetguitarpoetFri, 24 Mar 2006 03:58:00 GMThttp://www.blogjava.net/guitarpoet/archive/2006/03/24/37180.htmlhttp://www.blogjava.net/guitarpoet/comments/37180.htmlhttp://www.blogjava.net/guitarpoet/archive/2006/03/24/37180.html#Feedback1http://www.blogjava.net/guitarpoet/comments/commentRss/37180.htmlhttp://www.blogjava.net/guitarpoet/services/trackbacks/37180.html
JavaEE原话：“Containers are the interface between a component and the low-level platform-specific functionality that supports the component. ”
翻译过来就是“容器就是底层的、与支撑平台相关的、对组件进行功能化支持的接口”。

难以理解？

通俗的解释就是，容器是一系列为了实现分层的概念而定义的一系列功能的平台无关的标准。它的主要用处就是平台无关性和底层操作封装性（Java的核心哲学）。

说白了，容器就是Java的核心哲学在企业级应用范围内的具体实现。

那么使用容器，能给我们带来多大的好处呢？

  1. 强制性分层：通过Java的接口定义机制和强类型编译器的支持，在底层就实现了分层的概念。即使顶层的实现十分没有经验，底层的分层还是可以辨认的。
  2. 底层操作封装：以服务端应用服务器为中心的三层企业开发涉及到的技术相当麻烦和复杂，但是之间又有相当多的共性，所以进行有效的底层次的封装是可行的而且是有必要的。这样开发人员的工作就可以建立在一个稳固的基础上，而不是靠自己的经验去应对这些问题。
  3. 平台无关性：这个也是Java的核心哲学，至于好处吗，我就不多说了
  4. 代码的重用可能性提高：记住，是可能性。具体的重用性要看开发的方式和开发后代码的质量。

就JavaEE而言，它的标准里面只有WEB容器和EJB容器，这两个容器已经充分体现了它们的概念。

但是，还有一种概念上的容器，它的概念与上述概念不同，所以被称作轻量级容器。

首先，轻量级容器不是接口的抽象，没有JavaEE概念中的部署和移除，从概念上说轻量级容器就是一个拥有IOC支持的Bean工厂。

从形象的角度上来看，轻量级容器是一个盒子，盒子里面装满了贴有标签的JavaBean，对外界而言，它是一个魔盒，只要给它一个咒语（咒语必须正确），它就能给你一个礼物。

轻量级容器目前而言没，有相应的标准，但是它的使用范围却比真正的JavaEE标准要宽泛得多（谁不喜欢礼物呢？）。
  • 首先，它是一个非常好的JavaBean工厂（谁没用过工厂模式？）
  • 其次，它能够给你的代码带来IOC支持（懒人最喜欢的生活方式莫过于东西自己来找它）
  • 再次，一般来说，轻量级容器都可以通过动态代理和字节码增强的方式提供AOP的支持

总而言之，轻量级容器是JavaEE容器概念的一种有力补充，它的用法更加灵活，适用的范围更广，从目前的经验上看，开发、测试和管理起来也要比标准容器对象开发起来简单。

  • 轻量级容器一般不会给你提供分布式和集群的支持，因为它的优点就是灵活而不笨重。
  • 轻量级容器就像作汉堡的那两块面包，你想吃什么就往里夹，但是汉堡好吃不好吃，主要就在你放进去的东西和搭配的手艺。
  • 轻量级容器不能强制的要求你分层
  • 轻量级容器的底层封装一般以模块加载进容器的方式实现。
  • 有的人不爱吃汉堡。

总体评价：

容器是Java的核心哲学的体现，而轻量级容器则是工程师开发文化的体现，它可以很灵活的帮助你，对你没有什么具体的要求。二者不会出现谁替代谁的情况。具体的使用方式，还得看你在设计时所处的情况。

更正一下： 就JavaEE而言，它的标准里面只有WEB容器和EJB容器是对它的服务端而言的。客户端还有Application Container和Applet Container两个容器。

guitarpoet 2006-03-24 11:58 发表评论
]]>企业级应用为什么要分层？http://www.blogjava.net/guitarpoet/archive/2006/03/20/36392.htmlguitarpoetguitarpoetMon, 20 Mar 2006 09:29:00 GMThttp://www.blogjava.net/guitarpoet/archive/2006/03/20/36392.htmlhttp://www.blogjava.net/guitarpoet/comments/36392.htmlhttp://www.blogjava.net/guitarpoet/archive/2006/03/20/36392.html#Feedback0http://www.blogjava.net/guitarpoet/comments/commentRss/36392.htmlhttp://www.blogjava.net/guitarpoet/services/trackbacks/36392.html
企业级应用（enterprise applications），其实是一个软件行业内部通用的一个术语。如果解释成通俗易懂的话来说，那就是一个企业范围内所使用的、基于计算机的稳定的、安全的和高效的分布式信息管理系统。
对于企业级应用而言它的分布式有两种形式：B/S结构和C/S结构。由于浏览器的功能日益强大、网页技术的日益流行和应用服务器软件和中间件产品的逐步成 熟，B/S结构的企业级应用已经成为一种流行的趋势，所以在下面的讨论中所谓的企业级应用统一为基于B/S结构的分布式企业信息系统。

一般说来企业级应用都可以分为三层持久层（Persistence Layer） 、业务逻辑层（Business Logic Layer） 和展现层（Presentation Layer ） 。
为什么要分这么几个层次呢？
归根结底主要原因只有一个——那就是提高软件开发生产力，降低软件开发成本，提高软件产品质量。
因为软件公司也是资本公司，公司的主要目标是盈利而不是科技发展。所以，公司的技术架构的优劣主要应该体现在公司的生产成本和产品的质量上。
对于降低软件产品的开发成本是软件产品出现以来所有软件公司所追求的目标。到目前为止，达到这个目标的方式有这么几种：
  1. 把 软件产品根据功能进行分解，分别开发：对于大的复杂系统，如果没有很好的分解开发的话，其结果是不可想象的。现实中企业需要分开各个职能部门，它们的职责 和业务是不同的，这样开发中需要根据业务进行任务分解，把大的系统分解成为小的业务系统。这样才能够实现系统开发过程中的并行开发，并且会培养业务专精人 员，提高开发的效率。
  2. 业务系统根据技术架构进行分层开发：分层的开发方式实现了人类对复杂事物的普遍处理方式——分而治之。通过把复杂的系统分解成为相对简单的独立系统，低耦 合的分解既可以实现开发人员的并行工作，又可以实现开发人员的任务分工。而且通过分层，对组件拼装和流水化作业提供了理论和事实的基础。
  3. 组件拼装实现社会化分工：不必自己去创造轮子，直接付钱去买想要的轮子即可。这是从传统的制造行业借鉴来的经验。J2EE得到的广泛认同从实质上体现了业界对这种方式的肯定。
  4. 过去经验的积累和积累资源的重复利用：重用一直是一个争议比较大的东西，争论的双方各执一词，各有道理也各有大师助阵，但是那更多的是在理论上和技术层面 上。理论和技术上的争论对商业软件开发是无用的。因为商业化的软件开发，最重要的是提供优质的产品和服务并且能够最大可能的获取利润。所以，抛开具体实现 方式不谈，我个人觉得公司过去经验的积累和积累资源的重复利用是有商业价值的。因为软件公司必须得面对开发人员流动的问题，不管是升迁还是调动还是跳槽， 软件公司总会面对业务专精人员的流失问题。业务专精人员的流失造成的成本是要计算在开发成本中的，所以怎样以固化的形式积累业务人员的经验，和过去解决问 题的方案的可重复利用以及新员工职业培训成本的降低在降低开发成本的方面是值得考虑的。
综上所述，对于一个企业级应用框架（还有人开发企业级应用不用框架吗？）而言，分层是提高开发效率、降低开发和培训成本的最佳实践方案之一。
但是，为什么要分为持久层（Persistence Layer） 、业务逻辑层（Business Logic Layer） 和展现层（Presentation Layer ） 3层呢？
其实这三层不过就是从三个不同的视角去看这个企业信息系统罢了。从数据的角度看，企业信息系统不外乎就是对数据的存取。从功能的角度看，企业信息系统就是 对现实中的业务逻辑操作的信息化抽象而从用户的角度上看，它是一个人机接口，它可以接受输入并且会对所做的输入做出相应的反应。这三层从底向上实现了底层 计算机数据和顶层人的业务操作的跨越，一般说来，从概念上讲，所有的企业级应用框架都可以分成这三层，因为这三个视角是客观的。但是这并不保证所有的企业 级应用都能保证这三个层之间不发生耦合。

guitarpoet 2006-03-20 17:29 发表评论
]]>