业务逻辑层的封装设计

在系统开发中，通常都会采用经典的三层或者四层架构。其中数据模型层通过ORM工具来生成模型代码，实现了数据库操作的CRUD方法，上层的业务层进行简单的封装，供界面层调用。但由于模型层是与数据库中的单个表对应，而很多数据模型之间是有关联和上下级关系的，如果仅仅对业务层做简单封装，作为传值和分层之用，则很可能在开发和维护中出现以下问题：

1. 上层界面在增加和修改数据时，需要维护数据之间的关联和上下级关系；

2.上层界面调用删除等操作时，需要处理级联删除相关数据；

3.上层界面在操作某个数据的下级菜单时，通常要重新获取，增加了数据库访问次数；

4.上层界面在根据用户选择的数据来控制操作菜单时，需要重新加载权限信息，进行复杂的权限判断； 

5.通常的数据修改操作都需要记录日志，则界面层有大量的日志记录代码；

6.在进行排序和移出（移进）操作时，需要大量代码来实现。

 

以上问题是我在C/S结构的应用程序开发中亲身经历过的，不知是否具有普遍性。于是，希望业务层能封装上述问题相关的“附加”信息，希望达到以下效果：

1.能够在移出（移进）时能自动判断两个数据之间是否支持该操作；

2.在常用的排序中业务对象能自我排序；

3.在用户选中某个数据时，能识别出用户权限，从而控制界面菜单；

4.将日志的操作封装成统一接口，并在数据修改发生时业务层自动记录，上层操作不知道日志记录；

5.将系统中的各类数据抽象成统一的资源接口。

按照以上的需求，对业务层进行了点儿封装，基本上达到了上述的几个需求，同时其它开发者在调用过程中感觉到很顺手和舒服，代码量也减少很多，便于系统的升级和维护，上层调用代码示例如下：

// 将当前选中数据按名称排序
IDataResource resource = resPad.GetSelectedResource();
if (resource == null )
return ;
resource.SortByName();
resPad.RefreshNode(resource);

// 权限判断
IDataResource resource = resPad.GetSelectedResource() ;
if (resource != null && !resource .ReadOnly)
{
resource.Update() ;
}

// 数据移出
smDatasetDirectory dir = treeRes as smDatasetDirectory;
foreach (ListViewItem item in this .listViewUngroup.SelectedItems)
{
IDataResource res = item.Tag as IDataResource;
dir.MoveOut(res);
}

// 删除被选中数据资源及其下级
IDataResource resource = resPad.GetSelectedResource();
resource.Delete();

// 添加数据
smLayer layerLogic = new smLayer( " layer1 " );
mapLogic.AddResource(layerLogic);

示意类图如下：

主要类图：

设计要点：

1.所有业务对象都是数据资源（甚至包括用户和角色等），统一实现顶级接口；

2.顶级的虚基类实现大部分通用功能（比如日志记录和排序等），各业务对象只关心自身的特别业务； 

3.业务对象除了包含模型数据，应该是自我描述的，标识自身数据资源的类型，具有权限信息； 

4.业务对象自身知道能够与哪些对象发生关系，比如是否能移到某个资源下；

5.业务对象能够知道自己的上级资源是哪个，下级资源是哪些；

6.当业务对象被执行某种数据库操作时，应该能自动记录下相关操作日志，不必由上层调用来关心日志。 

 

以上是我的一点儿设计实践，欢迎大家拍砖！

代码下载：BusinessLogicCommon_src.rar

转载于:https://www.cnblogs.com/qingteng1983/archive/2011/07/10/2102231.html