Expert one on one J2EE development without EJB 摘要（1）

 
 
数据库的分布。很多应用只需要使用一个数据库，这也就意味着它们不需要JTA、两阶段提交或者XA事务。这些高级特性都会招致不必要的性能损失，并且提高系统的复杂度。
 
利用现有的框架提供这些基础设施服务。如资源池缓存、线程管理、服务定位、数据层访问等。
 
对于那些真正需要对象分布的应用，EJB仍然是上佳只选。尤其是当它们完全用Java实现、或者用IIOP作为通信协议时。不过，这种应用比人们通常想象的少。
 
对于需要大量使用异步消息的应用，EJB也是不错的解决方案，因为用message driven bean处理一步消息非常有效。
 
时至今日，EJB在处理异步消息方面的优势也受到了来自轻量级阵营的挑战。apache组织属下的 Jakarta Common Messenger 是一个轻量级的、基于PLOJO的JMS消息框架。
 
EJB能够真正为项目提升价值的典型例子就是金融中间件的应用。
 
 
面向框架开放的方法
 
模板还应该包括构建脚本和必要的jar文件。一个模板，只应该提供占位符，而不是业务。
模板基于一个应用，而不是框架的话，多数会失败。
 
大项目分成几个小项目，是项目团队在可管理的范围之内。
 
单元测试工具 Mock Objects 和 easyMock
标准的构件工具。Maven。要管理专用于J2EE的任务，构建脚本比IDE更合适。
 
XML编辑器。XMLSpy  dtd，schema提供了完美的支持
 
 
测试覆盖率统计的工具 clover
 
性能度量工具分析应用程序的性能。Eclipse profiler
 
伪对
4000
象：没有真正对象应该具备的特征，如身份、状态、行为
 
 
 
第三章 各种架构
 
 
 
 
架构性构件：
业务服务层
表现层
数据访问层
 
服务层一般都是无状态的。无状态的服务层具有很高的可扩展性：无需状态复制，不必为每个客户端分配额外的资源。
j2ee中有状态的服务层主要通过两种模型实现：有状态session bean 和web层的会话（session）对象
 
尽可能使用无状态服务层设计应用系统。尽可能把状态保存在web层而不是业务逻辑层。
 
远程调用和本地调用的一个根本区别：按引用，还是按值。
 
 
运行在轻量级容器中的服务层。
 
在web服务器和J2ee web容器之间，可能还有一种分布式的边界。比如说：可能用apache作为http服务器，然后通过一个代理连接器，把请求送给后台的J2ee web容器处理。对于程序设计来说，这种分布化不像分布式对象那么有害，不影响实际的代码。影响性能。采用这个方案有安全方面的理由：这样做之后，J2ee服务器的所有部分就可以放在一个防火墙后面了。
 
 
逻辑分隔：逻辑分隔的首要意义，拥有一个严格定义的业务服务层。不过，要确保这些服务很容易就能够访问到，而且不能让UI与业务服务接口之间产生依赖。
 
 
采用轻量级容器，业务对象在本地运行，表现层可以直接调用业务接口：这也是一个客观的架构简化。
 
Spring框架的一个主要优势，就在于它的核心意图就是组织业务对象。无论是对于采用了Spring架构的应用系统，还似乎对于Spring框架本身，web层都只是业务对象框架上面的一个层而已。这样正确的强调了编码工作的重心。
 
web层应该很薄，应该搭建在服务层上面，其代码只是用来解释用户的操作，显示响应的结果。
 
如果你有一个严格定义的业务服务层，就很容易的在上面加一个远程门面，就想在上面实现一个很薄的web层一样。这样做能够接触远程调用技术和业务逻辑实现之间的耦合，所以这是一种很好的实践。因此，在服务层接口定义中不应该包含传输对象，除非是出自设计本身的自然考虑。传输对象一般应该当成远程门面的一部分来定义
 
由于大多数J2ee应用系统使用关系数据库，所以持久化技术的可选方案只要是透明的持久化技术以及给予SQL的数据访问技术。
 
 
J2ee模式中的“数据访问对象”就似乎这样一种混合多种策略的正确途径。它用一个DAO接口隐藏了持久化操作的细节。这样使用这个模式的业务对象就无需知道底层的持久化知识。
 
访问遗留系统--JCA
在一些应用服务器中，还使用了JCA集成各种持久化工具，实现JDBC连接池。
 
 
不用EJB的特制J2ee架构。整体结构没那么多规范性。这种结构通常是由web容器定义。很大程度上，系统的结构上，系统的结构要由架构师自己鼓捣出来。在这些架构中，所有的java对象都运行在同一个jvm中，不过，也可以实现系统的集群，办法是把整个web应用系统部署在多台服务器上。
web组件定位本地业务对象时，通常会使用singleton模式，或者某种特制的工厂。需要编程实现事物管理，可以使用JTA。
既然没法使用entity bean，所以数据访问只有两种方法：OR，jdbc。
 
潜在的缺点--缺少清晰的服务层--可以通过强制实行规范来解决：要求开发者对业务接口的使用和对业务对象的访问都必须保持一直。通常这都要用上某种工厂。
 
轻量级的容器，不编写针对容器的代码，也没有讨厌的寻址代码。
 
控制反转可以让轻量级服务器为你组装对象，也就是说，应用迪马不再需要编写资源寻址活合作对象寻址代码，应用对象也不依赖于容器的api。对象与合作者之间的依赖关系，通过普通的javabean属性或是构造函数的参数来提现，而IoC容器负责在运行时解析这些关系，所以应用代码中那种实现起来很繁琐、测试起来挺困难的寻址代码就完全用不着了。
 
petStore采用了一个基于命令command的web框架，该框架从概念上就不同于目前流行的web框架。
 
相对于说问题的复杂度来说，以上两个系统都用了太多的代码。代码重复繁琐，往往通过工具生成而不是手写。对于web应用来说，j2ee这个技术比较糟糕。
 
每个DAO类都直接使用JDBC，没有任何的抽象层。
 
 
一个新的应用系统是不是需要完整的、支持JTA、JCA以及EJB的应用服务器。
 
优秀的web容器对应用系统的故障恢复和集群都提供了强大的支持，所以不一定总是需要应用服务器来保证扩展性和可靠性。
 
轻量级容器架构与其他各种不同EJB的架构的区别，在于它认识到一个定义一个清晰的服务层的重要性。它同样用到了容器，不过比起EJB容器来就便捷了很多，这个容器也能够提供声明式的企业级服务。对于标准的web服务，提倡使用这个架构。
 
 
 
简单性的红利
 
复杂的架构和代码表现出的性能往往是低下的。层次太多、抽象太多、远程调用太多：这些都会导致低下的性能。
 
TO，是传输对象的所写，To是j2ee架构设计中常用的一种模式，使用普通java对象在远程层之间传输数据。
 
没有任何人见到过分别部署web容器和EJB容器的方案运行效果胜于并置方案。
 
总结的显示经验：所谓分离servlet层和业务对象层的方法根本就是不可信的。强加于系统之上的远程调用，其实根本就没有扩展性。
 
对于并置方案来说，每个应用服务器都装载了所有的j2ee组件，包括web层和业务对象。
 
为了实现可扩展性，一种更好的途径往往是对整个应用系统实现集群式部署，然后，在利用硬件负载均衡活着web容器的负载均衡来分流访问。这样一来，并置架构很容易就能横向的获得扩展，只需要添加若干服务器，在上面运转整个应用系统即可。
可能真正限制可扩展性的地方，很可能在于底层数据库。