轉(zhuǎn)自：?https://blog.csdn.net/t0404/article/details/51865174?

?

貧血vs富血?

我們來回顧一下。在企業(yè)架構(gòu)模式中，業(yè)務(wù)層的實現(xiàn)一般有兩種模式：一種是事務(wù)角本模式（Transaction script），另一種是領(lǐng)域模型模式（Domain Model）。這兩種分別對應(yīng)貧血和富血。好吧，我們不說這些扯淡的東西，我們簡單點說。?

所謂貧血，就是一個對象里只有屬性，如java中的pojo，要實現(xiàn)業(yè)務(wù)，要依靠service層來實現(xiàn)相關(guān)方法，service層的實現(xiàn)是面向過程的，也就是所謂的transaction script.我們現(xiàn)在大量的分層應(yīng)用action->service->dao->entity的方式就是這種貧血的模式實現(xiàn)。?
?

Java代碼??

//貧血代碼示例：??

Account.java??

Public?class?Account{??

????private?String?name;??

????private?Long?num;??

????get?set…??

??

}??

??

AccountService.java??

Public?class?AccountService{??

????public?List?findAccountBySomething(String?abc){}??

????public?void?addAccount(Account?a){}??

????public?void??otherBiz(){}??

??

}??

所謂的富血就是屬性和方法都封裝在Domain Object里，所有業(yè)務(wù)都直接操作Domain Object。Service層只是完成一些簡單的事務(wù)之類的，甚至可以不用service層。也就是直接從action->entity.?
?

Java代碼??

//富血代碼示例??

Account.ava??

Public?class?Account{??

????private?String?name;??

????private?Long?num;??

??

????public?List?findAccountBySomething(String?abc){}??

????public?void?addAccount(Account?a){}??

????public?void??otherBiz(){}??

}??

前人總結(jié)的一些貧血和富血的對比：?
貧血模型的優(yōu)點：?
1.被許多程序員所掌握，許多教材采用的是這種模型，對于初學(xué)者，這種模型很自然，甚至被很多人認為是java中最正統(tǒng)的模型。?
2.它非常簡單，對于并不復(fù)雜的業(yè)務(wù)(轉(zhuǎn)帳業(yè)務(wù))，它工作得很好，開發(fā)起來非常迅速。它似乎也不需要對領(lǐng)域的充分了解，只要給出要實現(xiàn)功能的每一個步驟，就能實現(xiàn)它。?
3.事務(wù)邊界相當清楚，一般來說service的每個方法都可以看成一個事務(wù)，因為通常Service的每個方法對應(yīng)著一個用例。?
其缺點為也是很明顯的：?
1.所有的業(yè)務(wù)都在service中處理，當業(yè)越來越復(fù)雜時，service會變得越來越龐大，最終難以理解和維護。?
2.將所有的業(yè)務(wù)放在無狀態(tài)的service中實際上是一個過程化的設(shè)計，它在組織復(fù)雜的業(yè)務(wù)存在天然的劣勢，隨著業(yè)務(wù)的復(fù)雜，業(yè)務(wù)會在service中多個方法間重復(fù)。?
3.當添加一個新的UI時，很多業(yè)務(wù)邏輯得重新寫。例如，當要提供Web Service的接口時，原先為Web界面提供的service就很難重用，導(dǎo)致重復(fù)的業(yè)務(wù)邏輯（在貧血模型的分層圖中可以看得更清楚），如何保持業(yè)務(wù)邏輯一致是很大的挑戰(zhàn)。?

富血的優(yōu)點是：?
1.領(lǐng)域模型采用OO設(shè)計，通過將職責分配到相應(yīng)的模型對象或Service，可以很好的組織業(yè)務(wù)邏輯，當業(yè)務(wù)變得復(fù)雜時，領(lǐng)域模型顯出巨大的優(yōu)勢。?
2.當需要多個UI接口時，領(lǐng)域模型可以重用，并且業(yè)務(wù)邏輯只在領(lǐng)域?qū)又谐霈F(xiàn)，這使得很容易對多個UI接口保持業(yè)務(wù)邏輯的一致(從領(lǐng)域模型的分層圖可以看得更清楚)。?
富血的缺點是：?
1.對程序員的要求較高，初學(xué)者對這種將職責分配到多個協(xié)作對象中的方式感到極不適應(yīng)。?
2.領(lǐng)域驅(qū)動建模要求對領(lǐng)域模型完整而透徹的了解，只給出一個用例的實現(xiàn)步驟是無法得到領(lǐng)域模型的，這需要和領(lǐng)域?qū)＜业某浞钟懻?。錯誤的領(lǐng)域模型對項目的危害非常之大，而實現(xiàn)一個好的領(lǐng)域模型非常困難。?
3.對于簡單的軟件，使用領(lǐng)域模型，顯得有些殺雞用牛刀了。?
4.對于事務(wù)等的處理，如果完全DDD,java支持得不夠好。?

關(guān)于Spring roo?
引子中小胖公司就是采用Roo完成DDD富血開發(fā)。Spring Roo is a popular open-source rapid application development (RAD) tool for Java developers.?，使用命令行或工具操作來生成自動化項目，操作非常類似于rails。Roo可以很好的支持富血的Java DDD。關(guān)于roo我也不想說太多，因為我也沒有親自實戰(zhàn)過，大家可以google一下。?

如果采用roo,只需要?
對于一個業(yè)務(wù)實現(xiàn)?

Java代碼??

@Entity????

@RooEntity????

@RooJavaBean????

@RooToString????

public?class?Employee?{?????

????@NotNull????

????@Size(max?=?200)?????

????private?String?name;?????

????

????@Temporal(TemporalType.TIMESTAMP)?????

????private?Date?birth;?????

}????

??

//EmployeeController代碼如下：???

@RooWebScaffold(automaticallyMaintainView?=?true,?formBackingObject?=?Employee.class)?????

@RequestMapping("/employee/**")?????

@Controller????

public?class?EmployeeController?{?????

}???

在這里出現(xiàn)了一行@RooWebScaffold注解，做過rails的人會想，這不是rails里面的scaffold嗎？沒錯，通過@RooWebScaffold注解，EmployeeController自動獲得了curd的所有功能。?

好了，就這么簡單，一個domain，一個Controller，我們就可以發(fā)布到tomcat中運行了。?
?

引用

Roo功能目前還不很強大，比如還不能根據(jù)配置的數(shù)據(jù)庫鏈接直接從數(shù)據(jù)庫表來生成Entity，以及前端表示層使用JSP和綁定Spring MVC(基于Spring 3.0支持REST)等，但是這些改進目標已經(jīng)納入其roadmap中。說一下另一個框架Seam對于富血也做得不錯了，但還不是完全富血，同樣也綁帶了JSF。

這兩天又看了一下spring roo,修正一下觀點，新的spring roo版本已經(jīng)可以用DBRE reverse from db.并且好像也很強大。?

1.一個entity只需要寫屬性就行，get set免。?
2.簡單的增刪改查功能，一鍵生成。?
3.通過aspectJ實現(xiàn)編譯時aop，完全不影響性能。?
4.可以動態(tài)查詢：如findPersonByNameAndMinMax(),相當于like name,between min to max這樣的功能。?
5.用Spring roo實現(xiàn)DDD，只有兩層Controller層和Entity層。另外Service層（可選），Dao不推薦用了。?
6.jms,email,json序列化支持?
7.其它說明：開發(fā)需要JDK1.6以上。?
8.不想用roo時，可以快速刪除annotation和相關(guān)的jar包等文件。?
...?

Spring roo架構(gòu)overview：?

?


AspectJ實現(xiàn)編譯時AOP?

?


自動動態(tài)查詢，自動生成?

?



想了解更多roo內(nèi)容，可以看看此文：使用Spring Roo ，感受ROR式的開發(fā)?
http://www.iteye.com/topic/443059?
還有看官方文檔：?
http://www.springsource.org/roo?

關(guān)于ruby?
Ruby我沒有使用過，只是有所了解。所以不敢評價。但是當spring roo等框架成熟起來后，java語言就能很好的支持富血，更好的OO，更好的DDD，也能支持web快速開發(fā)了。那么我們能不能斗膽問一句：基于Java的開發(fā)者，想實現(xiàn)ror一樣的web開發(fā)，還需要ruby嗎？我們沒必要向ruby轉(zhuǎn)了吧？?


小結(jié)：?
我們對于新的東西，總是會有一種天生的阻抗性。就如我習(xí)慣了貧血的開發(fā)模式，有了更OO的spring roo出現(xiàn)時，我內(nèi)心里還是不大看好它。正如前些天一些人說spring越來越龐大，不好一樣，我想他們也是內(nèi)心的阻抗性在起作用。但一個人要有一個更高的視野，時刻準備一些東西，當風暴來臨時，可以從容面對。?

ps:說一下我的觀點：?
我是多年的貧血模型的實踐者，基本上并沒什么特別覺得不適的地方，雖然貧血模型不那么OO。其實我對于這個spring roo并不是特別看好。但是需要去了解它，和關(guān)注它。(可能又要修正了，看發(fā)展情況吧)?

國外有一篇文章對spring roo的觀點，我是比較贊同的:?
When to use Spring roo??
http://java.dzone.com/articles/when-use-spring-roo?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+javalobby%2Ffrontpage+(Javalobby+%2F+Java+Zone)?
我抽出幾個重要的出來：?
What is Spring Roo??
“Spring Roo is a lightweight developer tool that makes it fast and easy to deliver instant results. Best of all, you code 100% in Java and get to reuse all your existing Java knowledge, skills and experience.?

Spring Roo is awesome for CRUD-Clients!?

Spring Roo is good for learning Technologies!?

Spring Roo is NOT good for complex Projects (yet)...?

Conclusion: Spring Roo is a nice Tool => Become a Part of the Community!?
My final conclusion: You should know Spring Roo, because it is nice, but you should also know when to use it and when to use something else. Use it to create CRUD applications or to learn technologies.?Do not use it (yet) for complex, large projects.?

總結(jié)

以上是生活随笔為你收集整理的（转）贫血和富血的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。