Sloth 简介(二)
首先，谢谢大家的关注，为了让大家进步了解Sloth，我们将会在尽快上传介绍文档，
并逐步整理发布Sloth的源代码和一些辅助文档；
上一篇文章中只是简单介绍了Sloth的一些功能，在这篇文章中，我们将具体介绍Sloth
的一些操作；
相关链接：
组装业务
1． 为什么要使用组装业务
在拥有 Sloth 之前我们需要完成一个业务逻辑时一般采用的习惯模式是——将所有符合该
业务使用的相关类以 reference 的模式包含在这个业务包（以一个动态链结库或一个解决方案
中的项目存在）中，整体编译——这能迅速满足当前实现业务逻辑的需要，快速生成需要部
署的业务，在一定程度上使程序员的步进跟踪调试变得简单。
看起来不错，是吗？那么再让我们深入的想想下面的几个问题：
-
程序员交付给测试人员的代码相互交织，测试工作的颗粒性如何有效保证？
-
如果业务逻辑所引用的底层库不得不重构，需要重新提交给测试人员多少代码？
-
务逻辑本身的错误？ -
-
编译模块？
传统模式是紧密耦合的，项目后期由于业务需求变动——很不幸，这样的变动往往无法
避免——所需要的修改本身涉及的面很可能非常广，甚至异常复杂。这造成仅仅处于开发
阶段时，整个项目的可维护性和可管理性就无法保证！项目可控性的急剧下降，不仅是开发
时间的延长，工作量更会快速增加！
是否可以设想，如果只是在表示层申明一个对业务调用的别名，而不用具体处理业务是
怎样完成的，一旦发生重构性的修改，除非是对业务的重组，表示层也不会发生变动！于是，
我们仅需要着手于业务组件的细化，通过配置文件，就可以进行业务的调整。
下面让我们看看Sloth的处理。
Sloth与业务组件的通讯依赖于一个 Xml 配置文件（ControlBus.xml）进行交互，这个文件
中记录了需求管理者和软件设计师对业务过程的配置信息。就是说，改变了 Xml 中指定业
务的配置过程顺序，同时也会改变Sloth对该业务逻辑的执行效果。下一节，将有一个例子来
说明Sloth的处理模式。
2． 如何使用组装业务
示例业务：客户端程序录入个人基本信息及部门名称，系统自动获得“部门名称”对应
的部门编号，最后将个人信息及部门编号保存到数据库；
首先编写服务程序，分别实现两个业务逻辑：
Ø 个人信息保存：
public class ExamplePersonnel
{
……………………..
/// <summary>
/// 根据录入信息产生合适的sql语句 /// </summary> /// <param name="deptNo">部门编号</param> /// <param name="name">职员姓名</param> /// <param name="sex">性别</param>
/// <returns></returns> public string SavePersonnel(int deptNo, string name, string sex) { ///构造sql string result = null; try { result="insert into xxx (deptNo，name,sex) values ("+deptNo.ToString()+",'"+name+"',"+"'"+sex+"')"; } catch { } return result; }
}Ø 根据部门名称获得部门编号
public class ExampleDept { …….. …….. /// <summary> /// 根据指定的部门名称查找该部门的编号 /// </summary> /// <param name="deptName">部门名称</param> /// <returns></returns> public int search(string deptName) { ///根据指定的部门名称查找该部门的编号 int result = 0; try { DataRow[] searchRow = deptTable.Select("deptName" + "'" + deptName + "'"); if (searchRow.Length==1) { result = int.Parse(searchRow[0]["deptNo"].ToString()); } } catch { } return result; }} 以上，我们完成了业务组件的编写，当然我们需要一个通用的数据库操作组件，类似于
下面的结构（业务层与数据层同样是断耦的！）
public class DataAccess { public DataAccess() { } /// <summary> /// 执行传入的SQL语句,操作成功返回true,否则返回false; /// </summary> /// <param name="execSQL"></param> /// <returns></returns> public bool Execute(string execSQL) { bool result = false; try { //这里写保存数据的动作; } catch { } return result; } }
业务组件及数据操作组件都有了，可是我们并没有完整的实现业务逻辑，
在Sloth下，业务方法的组合是很简单的事：
打开Sloth的配置工具，首先将编写的业务组件（只需要dll或exe等文件）
添加到Sloth中，如图
这时就能在配置工具的[注册业务组件]下看到这个业务组件了；
双击这个业务组件，就可以看到组件中包含的几个类：
我们看到这个业务逻辑涉及到三个必要的方法，SavePersonnel需要的是部门
编号而不是部门名称，所以我们在执行SavePersonnel方法前，必须先得到部门编号，
也就是说，我们执行的顺序应该是先使用search方法得到部门编号，并将部门编号
传递到SavePersonnel中构造SQL语句，最后，构造好的SQL交由数据操作方法
Execute去执行，完成整个业务逻辑；
配置业务逻辑流程如图：
2.1 设置（SavePersonnel）方法的参数来源及下一节点
如图所示：SavePersonnel的deptNo参数来源于search方法的返回参数
2.2 整个流程的配置图（图形界面）：
业务逻辑配置完成后，可自定义虚拟业务名称，例如SavePersonInfo。虚拟
业务的配置信息保存于配置文件中（ControlBus.xml），Sloth将根据此配置文件
来调用业务组件，您甚至可以直接修改配置文件来更改、重组业务。
接下来,我们看看客户端怎么调用这个业务:
整个虚拟业务返回值为最后一个方法Excute的返回值（Bool类型）,所以,我们
的客户端代码就应为:
//目前sloth使用Object[]传递参数。 object[] parameters =new object[3]; parameters[0]="QuartetLounge Team"; parameters[1]="QuartetLounge"; parameters[2] = "Man"; //调用组合函数 bool result = targetSloth.Invoke<bool>("SavePersonInfo", parameters);//只需要调用我们自定义的虚拟业务名 string strCaption = null; if (result) { strCaption = "保存成功"; } else { strCaption = "保存失败"; }
这样就可以完成虚拟业务的调用了.这时一旦发生业务变化,我只需要修改业务逻辑
配置;如果发生了业务重构,也只需将变动的业务组件重新拷贝覆盖以前的业务组件即可。
至于事务控制，目前Sloth支持分布式事务控制（DTS）,但是默认关闭，需要在
配置工具中做相应设置即可。以后将详细讲解。
3． 目前存在的不足
3.1 . 组装业务的入口方法必须首先拖拉到图形配置页面;
3.2. 业务组合后,目前只能以最后一个方法的返回类型作为整个虚拟业务的返回
类型;
这些缺陷我们会在以后的版本中逐步完善,也希望大家都来参与或提出建议;
后话
最后，QuartetLounge Team感谢大家的关注，我们将尽快发布更详细的介绍文档及源代码。
近期还将发布演示视频。希望大家多提建议。
