迭代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模式，我们需要做 以下两件事