在系统开发中,通常都会采用经典的三层或者四层架构。其中数据模型层通过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.当业务对象被执行某种数据库操作时,应该能自动记录下相关操作日志,不必由上层调用来关心日志。
以上是我的一点儿设计实践,欢迎大家拍砖!