Sloth 简介(二)
首先，谢谢大家的关注，为了让大家进步了解Sloth，我们将会在尽快上传介绍文档，
并逐步整理发布Sloth的源代码和一些辅助文档；
上一篇文章中只是简单介绍了Sloth的一些功能，在这篇文章中，我们将具体介绍Sloth
的一些操作；
相关链接：
关于我们的 OpenSource 的想法（一）
Sloth 简介（一）
组装业务
1． 为什么要使用组装业务
在拥有 Sloth 之前我们需要完成一个业务逻辑时一般采用的习惯模式是——将所有符合该
业务使用的相关类以 reference 的模式包含在这个业务包（以一个动态链结库或一个解决方案
中的项目存在）中，整体编译——这能迅速满足当前实现业务逻辑的需要，快速生成需要部
署的业务，在一定程度上使程序员的步进跟踪调试变得简单。
看起来不错，是吗？那么再让我们深入的想想下面的几个问题：
-
程序员交付给测试人员的代码相互交织，测试工作的颗粒性如何有效保证？
-
如果业务逻辑所引用的底层库不得不重构，需要重新提交给测试人员多少代码？
-
如果测试人员检测出 bug，如何界定这个 bug 源是底层提交的数据性错误还是业
务逻辑本身的错误？
-
如果是一个大的解决方案，我们在开发阶段需要整合编译多少次？
-
如果个别模块版本更新，我们需要整合编译多少次？我们又需要重新发布多少已
编译模块？
传统模式是紧密耦合的，项目后期由于业务需求变动——很不幸，这样的变动往往无法
避免——所需要的修改本身涉及的面很可能非常广，甚至异常复杂。这造成仅仅处于开发
阶段时，整个项目的可维护性和可管理性就无法保证！项目可控性的急剧下降，不仅是开发
时间的延长，工作量更会快速增加！
是否可以设想，如果只是在表示层申明一个对业务调用的别名，而不用具体处理业务是
怎样完成的，一旦发生重构性的修改，除非是对业务的重组，表示层也不会发生变动！于是，
我们仅需要着手于业务组件的细化，通过配置文件，就可以进行业务的调整。
下面让我们看看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感谢大家的关注，我们将尽快发布更详细的介绍文档及源代码。
近期还将发布演示视频。希望大家多提建议。
posted on 2006-10-24 18:04
QuartetLounge 阅读(542)
评论(9) 编辑 收藏 网摘 所属分类:
Core Framework