without EJB notes (整理中)

一个架构究竟是简单还是幼稚，我们怎么判断：
一个架构可达到的简单程度，应该取决于业务需求，而不是技术平台。理想情况下，在项目周期的前期，架构满足业务需求的能力就可以用经验方法评测出来，而不是全凭主观臆断、一厢情愿。

XP(极限编程)一个核心观念就是：选择能够奏效的最简单的做法。对J2EE来说这个观念尤其重要。如果能够找到符合业务需求的最简单的架构，那就会带来巨大的收益。

XP(极限编程)教导我们：切实过分推断需求。别去实现那种两年后才能用上的潜在需求。那些需求可能永远也用不上，即使真正出现这样的需求，其形式也可能不同于你的推断。两年后，我们这位全知全能的架构师可能早就不在这个项目上了，而今天提出的解决方案，可能也根本无法满足那时的需求。

生产率，面向对象，业务需求至上，重视经验过程。

EJB相关的技术中，最好用的东西，都是那些最简单的东西：SLSB(无状态会话Bean)、MDB(消息驱动Bean)，而最复杂的部分EntityBean基本上没用。

本书的一个主要论题：介绍如何降低J2EE应用系统的复杂性。贯穿全书的关注点在于：

1.如果把精力集中在问题领域上，而不是只关注J2EE技术本身。
2.EJB的简化替代方案，这些方案应提供各种企业级服务(如事务管理)。
3.避免编写复杂的冗余代码，避免开发专用的基础架构。

以下经验有助于开发尽可能简单的J2EE架构：

1.如果没有充分的原因，不要使用分布式架构。只有当存在真正的业务需求——如需要远程JAVA客户端的时候，再使用分布式对象。
2.如果没有充分的原因，不要使用EJB。
3.不要开发复杂的内部专用基础架构。选择现成的方案，如开放源码方案。
4.今天就不要过度考虑明天的问题，若考虑这些问题会产生额外的花费和复杂性的话。
5.努力理解业务需求，因为应该由这些需求，而不是由技术平台决定系统架构。
6.在选定复杂的架构之前，应该先找到切实的证据(无论是在性能方面，还是其它指标)。比如说，若你要选择分布式架构这样的复杂方案，那么应该“先问问计算机”。

依赖注入的基本原则：应用对象不应该负责查找资料或者其它依赖的协作组件。配置对象的工作应该由IOC容器完成，“查找资源”的逻辑应该从应用代码中抽取出来，交给容器负责。
这样做的好处：(1)查找定位操作与应用代码完全无关。(2)不依赖容器的API。(3)不需要特殊的接口。


何时选择O/R映射：

1.针对领域对象的“加载/编辑/存储”流程，例如先加载一条产品记录，对其进行修改，然后更新回数据库。
2.对象以批量查询的方式取出，但更新和删除则是单独进行。
3.大量对象需要积极地缓存(通常出现在“读操作远多于写操作”的情况下，如web应用)。
4.在领域对象与数据库/字段之间有一个相当自然的对应关系。
5.不需要对SQL进行特别的优化。在大多数时候，好的O/R映射解决方案可以把生成的SQL优化得相当好，例如Hibernate的“方言”支持；但一些特殊的SQL优化只有在完全关系型的方式下才可能进行。


请牢记分布式计算的第一法则：不要分布你的对象。



架构(架构方面的指导方针)：

1.除非业务需求有必要，否则不要使用分布式架构。
请牢记分布式计算的第一法则：不要分布你的对象。J2EE并非天生的分布式平台，比起集中式应用，公布式应用的速度要慢得多，而且编写和维护都更加复杂。照我们的经验，web应用很少能从分布式架构获益。

2.在使用EJB之前，充分考量它的价值。
EJB会增加系统的复杂度。在某些时候，它也可能降低一些复杂度，如在需要分布能力的时候。所以充分衡量EJB的投资收益比是很有比较的。在没有周全考虑之前，不要贸然决定使用(或者拒绝)EJB，而且你的考虑应该有事实证据的支持。

3.如果决定使用EJB，请用POJO实现业务逻辑，然后在前面加上EJB facade。
如果你决定使用EJB，在利用它提供的服务的同时，你应该尽量避开EJB给开发过程带来的复杂性。为此，你应该尽量避免直接在EJB中实现业务逻辑，而应该把业务逻辑放在POJO中，再为POJO提供EJB facade。这样，你可以在EJB容器外部测试你的大部分业务逻辑。

4.如果决定使用EJB，请尽量使用本地SLSB，除非你确实需要分布式的架构。
本地无状态Session Bean提供了EJB的绝大部分有价值的服务，同时避免了EJB的很多缺陷。

5.如果有很多事务性操作，请使用声明性事务管理。
如果没有多少事务需求的话，编程性事务管理可能比EJB和基于AOP的声明性事务管理要来得简单。然而，如果很多方法都需要事务管理，编程性事务管理就会造成严重的代码重复，增加出错的机率，并且给维护带来巨大的麻烦。容器管理的事务管理(CMT)曾一度被认为是EJB的杀手级功能。

6.考虑O/R映射是否适用于你的项目。
O/R映射适用于很多项目，但并非所有项目。如果你使用了关系型数据库，并且确实需要直接处理关系型概念，就不要觉得自己一定需要使用O/R映射。

7.如果O/R映射适用，选择一个透明持久化方案。
透明持久化有很多好处：它使领域对象可以包含业务逻辑，这些业务逻辑可以被多个用例共享。这样一来，领域模型就是由对象而不是哑数据容器构成的。在我们看来，这是非常重要的。像JDO和Hibernate这样的产品都提供了近乎完全透明的持久化功能，比entityBean灵活得多的O/R映射和更合理的编程模型。即便是在EJB应用中，也应该避免使用entityBean，Hibernate和JDO之类的技术都可以毫无障碍地在EJB容器中工作。

8.考虑每个业务对象的线程模型。
绝大多数无状态业务对象都可以简单地表现为允许多线程复用的单一实例。

9.在采用一种架构之前，考察它的性能潜力。
应用程序的性能和伸缩性很大程度上由架构而非实现来决定的。所以在进入正式开发之前，应该首先检验架构是否能够满足你的性能需求。