灵活运用设计模式和范型封装CRUD操作逻辑

　　现在我们所做的很大一部分工作其实就是CRUD,　我们的aspx.cs页面充斥着大量的CRUD逻辑．当需要修改的时候，就要花大量的时间去查找并且修改，每个页面都要修改，工作量很大．为什么会这样呢？我们没有对这个CRUD操作逻辑进行封装．通过模版方法等设计模式可以解决这一问题．
　　
　　一．怎么发现这个问题的
　　当做了很多项目以后，我发现到我写CRUD基本操作的时候，我所做的事情大部分有几步骤：
　　１．Update需要从数据对象Entity初始化到页面上,其他不需要．
　　２．然后对页面输入的数据进行检查．
　　３．检查没有错误的输入后，创建数据对象．
　　４．然后把数据对象写入数据库．
　　５．Read和Delete都非常简单．
　　
　　这几件事情做了很多遍了，可是为什么我要做这么多遍呢？我觉得一定可以封装他们．当我看到　<<深入浅出设计模式>>的模版方式时，来了灵感．我只要找到了CRUD的算法就可以封装他们．事实上，我已经找到了这个算法．以上就是这个算法的几个步骤，只不过并不是每步骤都要执行．

　　二．设计
　　知道需求后，下面就是设计了．如图：

　　　　

 　　这里我只要介绍AbstractAdd类．它是一个抽象类，封装了CRUD算法．开始我只队我的一个页面进行封装，但是我觉得应该可以同时对进行相同操作的其他页面也可以．但是，因为不同页面可能操作的值类型对象也是不一样的．所以我还需要把类型也进行抽象．范型可以满足这样的要求．

AbstractAdd
public abstract class AbstractAdd<T, WebPage>
        where WebPage : Page
        where T : new()
    {
        private IEntityControl<T, WebPage> entityControl;
        private ICache<T, WebPage> operateCache;        
        private ICRUDDao<T, string> cRUDDao;

        public IEntityControl<T, WebPage> EntityControl
        {
            set { this.entityControl = value; }
            get { return this.entityControl; }
        }

        public ICache<T, WebPage> OperateCache
        {
            set { this.operateCache = value; }
            get { return this.operateCache; }
        }       

        public ICRUDDao<T, string> CRUDDao
        {
            set { this.cRUDDao = value; }
            get { return this.cRUDDao; }
        }

        public void Add(WebPage page)
        {
            T entity = CreateEntity(page);
            if (entity != null)
            {
                if (CRUDDao.Create(entity) == 0)
                    OperateCache.SaveCache(CRUDDao.FindAll(), page);
            }
            else
                throw new Exception("Entity is null");
        }

        private T CreateEntity(WebPage page)
        {
            if (EntityControl.Check(page))
                return EntityControl.CreateEntityFromConytrol(page);
            else throw new Exception("Check control unsucessful.");
        }

        public void Bind(WebPage page)
        {
            if (IsBind())
            {
                EntityControl.BindControl(OperateCache.GetCache(page),page);
            }
        }

        public bool IsBind()
        {
            return true;
        }

        public abstract void Init();

        //public abstract bool Check();
        //public abstract T InitEntityFromConytrol();
        //public abstract void BindControl(IList<T> t);

        //public abstract int Create(T t);
        //public abstract IList<T> FindAll();

        //public abstract void SaveCache(IList<T> t);        
        //public abstract IList<T> GetCache();


    }

被注释的部分其实就是模版方法模式的原形，后来我把他们有抽象成了接口．

　　AbstractAdd抽象类依赖这三个接口，它们分别是：
　　IEntityControl接口抽象了页面控件和数据类型Entity之间转换的动作．
　　IOperateCache接口抽象了和缓存操作有关的动作，比如把从数据库读出的集合写入缓存和从缓存读取集合．
　　ICRUDDao接口是一个通用CRUD接口，通过这个接口让BLL和界面解偶．

　　三．谈谈学习设计模式

　　模版方法模式里并没有接口，我对进行了扩展．把Abstract里面的基本算法整体　的各个步骤分解出来，抽象成接口，这样就实现了算法只依赖于抽象的算法步骤，算法就针对了抽象编程，而没有针对实现编程．
抽象出来的接口可以任意扩展．例如：BLL成的业务对象就可以实现ICRUDDao接口，完成数据访问的操作．
不同的BLL对象有不同的实现ICRUDDao接口的策略，其实这又是策略模式了．

　　学习设计模式这么长时间，最大的感受就是不能光去记每个模式的代码怎么写，重要的是要理解他们的不同意思，封装的是什么变化，用到了什么设计原则等．其实，在我看来，有些模式的本质都是一样的，这就是为什么你发现模式的结构图非常相似．他们只不过封装了不同的变化而已，比如：工厂模式封装了因要创建不同对象而产生的变化，迭代器模式封装了因使用不同集合而产生不同迭代的变化，但是他们的本质却是一样的．

　　四．说明
　　这篇文章中介绍的做法只适合没有关联CRUD操作，如果你的领域模式建立的非常好，关联很多，那就要用ORM了，目前我也只实现了单个CRUD操作的．不过现在哪里有真正的领域模型呢！关联的字段都作成属性了．呵呵！这样也是可以用的．我们做的这个项目就是这样的，我也是因为这样才有做这个东西的冲动．

示例代码可以在这里下载．