至于Product和ProductRepository的代码就非常简单了,这里不多解释。
示例到这里,也许大家有个疑问:上面的代码有些什么问题?
q ProductService依赖于ProductRepository。在没有任何变化的情况下,这没有什么问题。但是如果现在项目换了数据存储设备,例如将数据库换成了XML文件,或者数据库的访问技术从ADO.NET 换成了Entity Framework,那么ProductRepository的代码就得改变,这会使得整个项目都需要重新编译,重新部署。问题来了:此时系统中只有ProductRepository一个变化点,为什么非得要求整个项目重新编译,重新部署呢?难道不能只重新编译和部署那个变化的模块呢?
q 代码不具有测试性能。要想知道此段功能代码是否按照了我们的意愿运行,可以通过人工审核,然后通过GUI界面获取数据来进行调试,此时的逻辑相对而言比较简单,此方法也还行得通。不过,一旦业务逻辑变得复杂或代码量的剧增,那么很难确保代码不会出错,而这些错误很多时候只会在运行时才能被发现。
q 缓存机制依赖于HttpContext,这不仅仅会让测试产生困难(尽管可以有Mock),而且会对后续系统的扩展有阻碍(例如采用分布式缓存)。
对以上的问题进行进一步分析,可以知道,这都是因为违背了以下设计原则:
q ProductService依赖了ProductRepository的具体实现,而ProductRepository是一个可能的变化点。也就是说:ProductService这个高层模块依赖了ProductRepository底层模块,违背了依赖倒置原则,这也就使得一个ProductRepository变化,整个项目都需要重新编译,重新部署。同理,缓存机制也是。
q 对于可测试性的问题,严格来说,上面的代码是可以测试的,但是测试的时候必须依赖于外部的数据存储设备,例如数据库,那么测试的结果可能会由于数据的变动而不一样,而且每次测试所花的时间也会比较长。
接下来尝试重构上面的代码,让代码的组织方式更加的灵活和易于扩展。
既然上面代码主要是违背了DIP依赖倒置原则(再次回顾一下DIP:依赖抽象,而不依赖具体实现)。
那么现在就提出接口IProductRepository,使得ProductService依赖这个接口,代码如下: