閱讀116 返回首頁    go 阿裏雲 go 技術社區[雲棲]

讀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."



最後更新：2017-04-02 22:16:39

  上一篇：go 終於離開了讓我又愛又恨的外包圈，附贈外包圈趣事及混外包圈秘籍
  下一篇：go 成員函數不能作為pthread——create的參數