[置顶] 常规功能和模块自定义系统 (cfcmms)—034模块间关联关系的优化的思路

034模块间关联关系的优化的思路

　　前台的各种自定义控件都是为了展示数据和操作数据，作为管理系统的颜面固然重要，但是后台的控制系统默默的为前台提供数据和完成操作任务则更为重要。本自定义系统的核心部分是如何处理模块的关联关系。由于我一直做一些中小型的政府管理软件，模块间树形关系比较明确，因此现在系统中的模块间的关系的处理只能是中规中矩的树形。比如我最早的一个博客里面举例的一个“销售系统”的业务模块如下图所示。

　　在上面的图中，11个模块的关联关系很直观，没有交叉，每一个模块只有单独的用处，层次关系清晰。现在的自定义系统对于这种关联关系的处理已经很好了。但是随着业务需求的深入，模块间的关联关系会更加复杂化。比如“订单”模块需要增加一个“发货仓库”的关联，发货仓库又有所属“市”的属性；再给“订单“增加“始发地市”和”目的地市“的关联，如下图所示：

　　上图的这个模块间的结构复杂了不少，主要是出现了非常规树的形状。在上一张图里，“市”模块其实就只能定义为“客户单位的市”，但是在这张图表里，“市”模块就同时要担任4个角色。“省”模块同样也是。对于权限控制来说，最主要的改变是：在上一张图里如果设置一个角色，只能查看江苏省的客户的信息，那么在省的模块上建立一个规则即可，是没有问题的。在下面的图里就有了问题了，如果把权限的值设在“省”上面，那么这个省到底对子模块要怎么控制呢？你是要查看江苏省的客户，还是江苏省的商品仓库，还是始发地是江苏的，还是目的地的江苏的呢？

　　现在的系统不能直接处理上图的模块结构，但是有一个变通的办法，就是建立4个市和4个省的影子模块，即要建立 商品仓库市、始发地市、目的地市、客户单位市，对于省份来说也要建立相应的4个省来对应。这个方法可以解决问题，但是在系统里面要多出8个bean文件，如果省市用在很多的模块上，那么会增加更多的bean文件。这个方法对于比较复杂的系统来说是行不通的。

　　鉴于以上的一些问题和实际的需求，需要对模块间的关联关系来重新设计，使其能够按照上图的关联结构来处理好各个模块的关系。上图显示的一共是12个模块，但是真正管理的应该有12－2+8＝18个模块。在处理订单的父模块“市”和“省”的时候，必须按照不同的条线将其理顺。

　　要将上图的模块关联关系生成如下图的常规树就好处理了。在系统中市和省仍旧只有一个bean，但是在处理关联关系的时候，必须分清是哪一个市或省。

　　在上图，可以明显的看清“订单”模块具有4个省和4个市，这样我们在设置权限的时候，或者在设置导航属性的时候，就可以指定是哪一个省份了。

　　在系统的内部处理上面，“省份”对“订单”就有4条线路可以达到。

　　　1.省－市－客户单位；

　　　2.省－市－商品仓库；

　　　3､省－市（始发地）;

　　　4、省－市（目的地市）;

　　同样的，省份对应“订单明细”模块，也有这四条路径可以走。

　　在综合查询的时候，可以设置为“客户单位省”、“商品仓库省”、“始发地省”、“目的地省”设置不同的查询条件，在分数的时候，还可以按这4种类型的省份来分类汇总。想想功能真是可以无限扩展。

　　要完成能够解析上图这样的模块间的关联关系，必须在底层进行重构了。需要重新设计模块的关联关系的定义，包括数据读取、导航、综合查询等等一系列的模块。这将是一个非常复杂的工作。