《.NET应用架构设计：原则、模式与实践》新书博客--试读-2.1.2 设计原则实战
2.1.2 设计原则实战 下面我们就以一个简单的电子商务系统为背景：通过给定的产品分类ID获取该分类下的所有产品。对于这个问题，基本上不用想就可以实现，如图2-1的类图设计。图2-1 获取分类产品的类图其中：q ProductService类被客户程序调用，通过调用GetAllProductsFrom方法来获取产品，并且此处还可以添加缓存策略或异常处理等机制。q Product类代表了产品的实体。q ProductRepository类用来从数据存储设备（数据库或XML等其他数据存储器）中读取产品信息。 注意 为了减少读者不必要的麻烦，让理解更加直观，以后的章节中，都会给出完整的代码示例和项目图示。在这个示例中，Visual Studio项目的结构图如图2-2所示。图2-2 Visual Studio解决方案图 正如之前所说：ProductService提供外部调用的方法接口，并且采用了缓存策略和异常处理机制，来提高程序的性能和健壮性，代码如下所示：using System;
usingSystem.Collections.Generic;
usingSystem.Web;
using AgileSharp.Chapter2.Repository;
using AgileSharp.Chapter2.Domain;
namespace AgileSharp.Chapter2.Service
{
public class ProductService
{
private ProductRepository productRepository = null;
public ProductService()
{
productRepository = new ProductRepository();
}
public List<Product> GetAllProductsFrom(intcategoryId)
{
List<Product> result = new List<Product>();
try
{
string cacheKey = string.Format("products_in_category_{0}"，categoryId);
result = HttpContext.Current.Cache.Get(cacheKey) as List<Product>;
if (result == null)
{
result = productRepository.GetProductsFrom(categoryId);
if (result != null &&result.Count> 0)
{
HttpContext.Current.Cache.Insert(cacheKey， result);
}
}
}
catch (Exception ex)
{
//Log will add here later
}
return result;
}
}
}
至于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依赖这个接口，代码如下：using System.Collections.Generic;
using AgileSharp.Chapter2.Domain;
namespace AgileSharp.Chapter2.Repository
{
public interface IProductRepository
{
List<Product> GetProductsFrom(intcategoryId);
}
}
现在接口已经抽象出来了，ProductService可以直接依赖接口了，但是我们现在还需要一个实现IProductRepository接口的类ProductRepository，然后再采用LSP（里氏替换原则），用ProductRepository替换。代码如下：using System;
usingSystem.Collections.Generic;
using AgileSharp.Chapter2.Domain;
namespace AgileSharp.Chapter2.Repository
{
public class ProductRepository：IProductRepository
{
//…
}
}
现在ProductService的代码如下所示：using System;
usingSystem.Collections.Generic;
usingSystem.Web;
using AgileSharp.Chapter2.Repository;
using AgileSharp.Chapter2.Domain;
namespace AgileSharp.Chapter2.Service
{
public class ProductService
{
privateIProductRepositoryproductRepository = null;
publicProductService()
{
productRepository = new ProductRepository();
}
public List<Product> GetAllProductsFrom(intcategoryId)
{
//...
}
}
}
其实可以看到，上面ProductService的代码虽然提出了抽象接口，但问题依然存在：仍依赖于ProductRepository的具体实现。 问题到这里就好办了，可以采用工厂模式，通过读取配置文件进行反射或采用依赖注入等方法得到解耦。 可以看出：设计原则解决了变化点的问题，将ProductRepository这个变化点从ProductService中移出，然后一步步的迁移，最后把这个变化点引到了配置文件中，也就是将变化点引到了系统之外，也许这些正是我们需要的。 当当网：http://product.dangdang.com/product.aspx?product_id=22574513京东地址：http://book.360buy.com/10893935.html 卓越地址：http://www.amazon.cn/mn/dp/B006NS2N0S
usingSystem.Collections.Generic;
usingSystem.Web;
using AgileSharp.Chapter2.Repository;
using AgileSharp.Chapter2.Domain;
namespace AgileSharp.Chapter2.Service
{
public class ProductService
{
private ProductRepository productRepository = null;
public ProductService()
{
productRepository = new ProductRepository();
}
public List<Product> GetAllProductsFrom(intcategoryId)
{
List<Product> result = new List<Product>();
try
{
string cacheKey = string.Format("products_in_category_{0}"，categoryId);
result = HttpContext.Current.Cache.Get(cacheKey) as List<Product>;
if (result == null)
{
result = productRepository.GetProductsFrom(categoryId);
if (result != null &&result.Count> 0)
{
HttpContext.Current.Cache.Insert(cacheKey， result);
}
}
}
catch (Exception ex)
{
//Log will add here later
}
return result;
}
}
}
至于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依赖这个接口，代码如下：using System.Collections.Generic;
using AgileSharp.Chapter2.Domain;
namespace AgileSharp.Chapter2.Repository
{
public interface IProductRepository
{
List<Product> GetProductsFrom(intcategoryId);
}
}
现在接口已经抽象出来了，ProductService可以直接依赖接口了，但是我们现在还需要一个实现IProductRepository接口的类ProductRepository，然后再采用LSP（里氏替换原则），用ProductRepository替换。代码如下：using System;
usingSystem.Collections.Generic;
using AgileSharp.Chapter2.Domain;
namespace AgileSharp.Chapter2.Repository
{
public class ProductRepository：IProductRepository
{
//…
}
}
现在ProductService的代码如下所示：using System;
usingSystem.Collections.Generic;
usingSystem.Web;
using AgileSharp.Chapter2.Repository;
using AgileSharp.Chapter2.Domain;
namespace AgileSharp.Chapter2.Service
{
public class ProductService
{
privateIProductRepositoryproductRepository = null;
publicProductService()
{
productRepository = new ProductRepository();
}
public List<Product> GetAllProductsFrom(intcategoryId)
{
//...
}
}
}
其实可以看到，上面ProductService的代码虽然提出了抽象接口，但问题依然存在：仍依赖于ProductRepository的具体实现。 问题到这里就好办了，可以采用工厂模式，通过读取配置文件进行反射或采用依赖注入等方法得到解耦。 可以看出：设计原则解决了变化点的问题，将ProductRepository这个变化点从ProductService中移出，然后一步步的迁移，最后把这个变化点引到了配置文件中，也就是将变化点引到了系统之外，也许这些正是我们需要的。 当当网：http://product.dangdang.com/product.aspx?product_id=22574513京东地址：http://book.360buy.com/10893935.html 卓越地址：http://www.amazon.cn/mn/dp/B006NS2N0S
声明：本站所有文章资源内容，如无特殊说明或标注，均为采集网络资源。如若本站内容侵犯了原著者的合法权益，可联系本站删除。
