迭代4 利用設計模式松散耦合
本次迭代
這是ContactManager的第四次迭代，本次迭代中我們將重構應用程序， 通過合理的利用設計模式松散其耦合。松耦合的程序更有彈性，更易維護。當應用程序面臨 改動時，你只需修改某一部分的代碼，而不會出現大量修改與其耦合嚴重的相關代碼這種牽 一發而動全身的情況。
在當前的ContactManager應用中，所有的數據存儲及驗證邏 輯都分布在controller類中，這並不是個好主意。要知道這種情況下一旦你需要修改其中一 部分代碼，你將同時面臨為其他部分增加bug的風險。比如你需要修改驗證邏輯，你就必須 承擔數據存儲或controller部分的邏輯會隨之出現問題的風險。
(SRP-單一職責原則 ), 就一個類而言，應該只專注於做一件事和僅有一個引起它變化的原因。將controller、 驗證及數據存儲邏輯耦合在一起嚴重的違反了SRP。
需求的變更，個人想法的升華、 始料未及的情況如此頻繁，你不得不就當前的應用作出一些改變：為應用程序添加新功能、 修復bug、修改應用中某個功能的實現等。就應用程序而言，它們很難處於一種靜止不動的 狀態，他們無時無刻在被不停的改變、改善。
現在的情況是，ContactManager應用 中使用了Microsoft Entity Framework處理數據通信。想象一下，你決定對數據存儲層實現 做出一些改變，你希望使用其它的一些方案：如ADP.NET Data Services或NHibernate。由 於數據存儲相關的代碼並不獨立於驗證及controller中的代碼，你將無法避免修改那些原本 應該毫無干系的代碼。
而另一方面，對於一個松耦合的程序來說，上面的問題就不 存在了。一個經典的場景是：你可以隨意切換數據存儲方案而不用管驗證邏輯、controller 中的那些勞什子代碼。
在這次迭代中，我們將利用軟件設計模式的優點重構我們的 Contact Manager應用程序，使其符合我們上面提到的“松耦合”的要求。盡管 做完這些以後，我們的應用程序並不會表現的與以往有任何不同，但是我們從此便可輕松駕 馭其未來的維護及修改過程。
重構就是指在不改變程序外在行為的前提下，對代碼 做出修改，改進程序內部結構的過程。
使用Repository模式
我們的第一個改 動便是使用叫做Repository的設計模式改善我們的應用。我們將使用這個模式將數據存儲相 關的代碼與我們應用中的其他邏輯獨立開來。
要實現Repository模式，我們需要做 以下兩件事
