首页 > 代码库 > WF4.0——升级技能:泛型应用

WF4.0——升级技能:泛型应用

前提:

        在项目的开发中,我们知道,加入泛型,通过对类型的封装,进行抽象后,可以大大减少我们代码量,在项目中,泛型可以说是高级工程师必备的技能之一,也是面向对象的核心“抽象”的技术基础之一,他这么牛,在工作流的开发中,我们不免就要考虑!

        还有一个技术,也是一个重要的内容,就是委托,在项目中,我们通过委托可以对层级之间,对象之间的关系就行解耦,将耦合延迟到运行状态时进行绑定,这样我们就能在改动较为少的前提下对项目的变动作出快速的反应!而在工作流的开发过程中,我们也是要加入的必备技术!(请关注我的下片博客)


原因:

        下面给大家介绍我们为什么加入这两种技术的原因:

        在普通的工作流开发中,我们在上篇博客中已经介绍过,他造成了一个严重的影响,就是结点太多了!我们看一幅图(实际项目中的例子,很有说服力)


        大家认真观察不难发现,我们将近有几十个结点,而这些点的开发将是我们噩梦的开始,我们每个人基本上都会发现,这个结点和其他几个结点只有几个不同的地方,90%都是相似的,而我们却傻傻地写了所有的代码,聪明一点的,还会复制粘贴,但是我们是面向对象的工程师,我们应该有更好的解决方案。

        而这时,我们自觉想到了泛型,他就是对类型的抽象,有了它,我们就可以只关心我们特定的逻辑,而根据客户端类型的确定,我们就可以复用公共的逻辑!

代码对比:

      一般代码:

<span style="font-size:18px;">public sealed class Activity_ToDo : CodeActivity
    {
        // 定义一个字符串类型的活动输入参数
        public InArgument<Login.Model.Entity.Case> CaseIn { get; set; }
        public OutArgument<Login.Model.Entity.Case> CaseOut { get; set; }

        // 如果活动返回值,则从 CodeActivity<TResult>
        // 派生并从 Execute 方法返回该值。
        protected override void Execute(CodeActivityContext context)
        {
            Login.Model.Entity.Case info = new Login.Model.Entity.Case();

            BaseEntityAbstract cache = new BaseEntityHelper();
            cache.GetTableInfo(typeof(Login.Model.Entity.Case));
            CommonData.Data.Core.SQLCore.SqlHelper sq = new CommonData.Data.Core.SQLCore.SqlHelper();

            info.Id = CaseIn.Get(context).Id;
            info.CaseName = CaseIn.Get(context).CaseName;
            info.State = "正在办理";
            info.InstanceID = CaseIn.Get(context).InstanceID;
            info.UserId = CaseIn.Get(context).UserId;

            sq.Update<Login.Model.Entity.Case>(info);
            info = sq.GetEntity<Login.Model.Entity.Case>("InstanceID", info.InstanceID);

            //CaseOut.Set(context, info);
            context.SetValue(CaseOut, info);
            //Login.Model.Entity.Case caseThisCon = context.GetValue(this.CaseOut); 
        }
    }</span>

使用泛型之后的代码:

<span style="font-size:18px;">public sealed class CodeActivityevent<T> : CodeActivity
    {

       
        /// <summary>
        /// 传入参数,案件实体
        /// </summary>
        public InArgument<T> CaseIn { get; set; }
        
        /// <summary>
        /// 传出参数,案件实体
        /// </summary>
        public OutArgument<T> CaseOut { get; set; }

        /// <summary>
        /// 执行创建案件
        /// </summary>
        /// <param name="context"></param>
        protected override void Execute(CodeActivityContext context)
        {
			//获取实体操作类
			BaseEntityAbstract cache = new BaseEntityHelper();
            cache.GetTableInfo(typeof(Login.Model.Entity.Case));
            CommonData.Data.Core.SQLCore.SqlHelper sq = new CommonData.Data.Core.SQLCore.SqlHelper();
			
            //获取传入参数的两种方法
            T CaseUse = CaseIn.Get<T>(context);
            //调用业务逻辑层,将获取的实体传入,接收返回的实体,并将其付给传出参数

            //TODO:基础活动:修改实体的逻辑层
            //返回的案件实体CaseBack
            T CaseBack = sq.Save(CaseUse);

            //将返回的实体传出
            //CaseOut.Set(context, info);
            context.SetValue(CaseOut, CaseBack);

        }
    }</span>



代码对比结果

    我们发现使用泛型后有几点好处:

        1,代码复用,这样我们多有的保存操作都可以用一个代码活动解决

        2,公共服务,我们规定好基本的代码结构后,想要给所有的公共服务增加一个功能,则只需改动一个类就可以

    我们又发现了几点工作流的好处:

        1,解耦逻辑,在逻辑处理这一层大部分有工作流性质的业务可以使用工作流泽合逻辑处理层,而工作流就是xml文件,所以他的改动是一个解耦行为

        2,扩充简单,我们在某一个小型复用工作流中,对其功能的扩充就是开发扩充模块,加入工作流就ok了

总结:

        我们使用任何技术,只要这个技术存在的时间够长,我们有理由相信,我们遇到的问题,前人肯定遇到过,他们肯定通过N种方法解决了这种困难,我们要做的就是找到他,研究它,在这个技术基础上先进行公共服务抽象,然后就是具体业务的编写,我们这个过程中,我们的收货,不仅仅是技术的获得,还有抽象理念的提升及面向对象的加深!像老师说,我们要在架构层面上进行开发!





WF4.0——升级技能:泛型应用