博客统计信息

51cto专家博客 51cto博客之星
用户名:yanyangtian
文章数:76
评论数:419
访问量:153913
无忧币:1663
博客积分:4234
博客等级:7
注册日期:2010-10-22

《.NET应用架构设计:原则、模式与实践》新书博客--试读-2.1.2 设计原则实战
2012-01-05 09:40:36
版权声明:原创作品,如需转载,请与作者联系。否则将追究法律责任。
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;

                }

        }

}
 
    至于ProductProductRepository的代码就非常简单了,这里不多解释。
 
示例到这里,也许大家有个疑问:上面的代码有些什么问题?
 
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中移出,然后一步步的迁移,最后把这个变化点引到了配置文件中,也就是将变化点引到了系统之外,也许这些正是我们需要的。
 

本文出自 “燕洋天” 博客,转载请与作者联系!

分享至
更多
一键收藏,随时查看,分享好友!
0人
了这篇文章
类别:.NET应用架构设计技术圈()┆阅读()┆评论() ┆ 推送到技术圈返回首页

文章评论

 
 

发表评论            

【技术门诊】专家解析:软考重点难点及应试技巧
昵  称:
登录  快速注册
验证码:

请点击后输入验证码博客过2级,无需填写验证码

内  容: