读Martin Fowler's 《Patterns of Enterprise Application Architecture》有感

作为一本技术指导书，显然这本书有些outdated了，但想想现在的一些框架，架构正是基于这本书的思想构建的，还是不免对作者当时的Vision感到钦佩。出于对这些思想本源的追索，以及对历史的追溯。还是很有必要浏览这本经典著作的，对于这个500页的书，我看的比较快，只是跳一些感兴趣的点着重看下，事实证明还是很有收获的。

POJO

• 起源：J2EE才出现时，尽管EJB2.0 特别是它的Entity Bean 给开发和调试带来了很多不便，但是在vendor的怂恿和对新技术的盲从下，很多公司还是采用了这个后来被证明是worst practice的技术。（记得当时我第一家公司就是用了CMB）作者认为人们忽略原来标准的java object 而去用这些container-based object 是因为这些regular java object没有个好听的名字，所以在准备2000 java one大会的时候，Rebecca, Josh and
  Martin give them one: POJO (plain old Java objects)
• 收获：我开始以为POJO就是贫血的Domain Object，里面只有fields and setter, getter。 而现在知道POJO是针对那些依赖框架的Java Objects而言的，不依赖任何框架的Java Object 就是POJO，依赖框架的坏处是调试和测试都很麻烦，像EJB2.0，Struts1等。
• 演变：现在的主流架构应该都支持POJO了，也就是实现类不需要依赖框架的Object了，例如EJB3.0, Struts2等

DTO

• 起源：作为Remote Call往往需要比较大的overhead，所以一个基本原则就是尽量减少remote call，这就需要我们暴露给client的interface最好是coarse-grained（粗粒度的），一个用来在不同App之间传输Data的Object DTO（Data Transfer Object) 应运而生了。
• 收获：开始以为DTO就是简单对DO进行1对1的wrap，所以很不理解这样做得必要性。其实DTO并不是对DO的1对1包装，而是一个DTO aggregates 多个DO的信息，这样client 就能在一次Call中得到足够的信息。
  引用原文的话：“If a remote object requests data about an order object, the returned Data Transfer Object will contain data from the order, the customer, the line items,the products on the line items, the delivery information- all sorts of stuff."