前提：

        在项目的开发中。我们知道，增加泛型，通过对类型的封装，进行抽象后。能够大大降低我们代码量，在项目中，泛型能够说是高级project师必备的技能之中的一个。也是面向对象的核心“抽象”的技术基础之中的一个，他这么牛，在工作流的开发中，我们不免就要考虑！

        另一个技术，也是一个重要的内容，就是托付，在项目中，我们通过托付能够对层级之间。对象之间的关系即可解耦，将耦合延迟到执行状态时进行绑定，这样我们就能在修改较为少的前提下对项目的变动作出高速的反应！而在工作流的开发过程中。我们也是要增加的必备技术！（请关注我的下片博客）

原因：

        以下给大家介绍我们为什么增加这两种技术的原因：

        在普通的工作流开发中。我们在上篇博客中已经介绍过，他造成了一个严重的影响，就是结点太多了！

我们看一幅图（实际项目中的样例，非常有说服力）

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

        而这时。我们自觉想到了泛型，他就是对类型的抽象，有了它，我们就能够仅仅关心我们特定的逻辑，而依据client类型的确定，我们就能够复用公共的逻辑！

代码对照：

      一般代码：

<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种方法攻克了这样的困难，我们要做的就是找到他，研究它，在这个技术基础上先进行公共服务抽象，然后就是详细业务的编写。我们这个过程中，我们的收货，不不过技术的获得。还有抽象理念的提升及面向对象的加深。像老师说，我们要在架构层面上进行开发。