在项目中,我们总是需要管理各种各样的类型数据(如产品类型、用户类型等),还有一些配置文件(通常是XML格式的文件),如果为每一种类型都建立一张表去维护或是使用配置文件,而且对每种类型通常还要进行增删改查的操作,并且我们不得不去了解每一个类型表的名字和配置文件的描述, 然后再关联它。那工作量是可想而之大,而且在测试环境和生成环境配置大多是不一样。
然而对这些类型、配置文件管理的方式都大多像似,于是框架设计出一个系统配置表的配置页面,专门用来管理配置文件和业务数据的类型,大大减少的代码量。生成环境和测试环境的配置都是可视化,减少在生成环境配置的出错率。介绍常见的几种常见的应用场景。已便于更好的理解这些应用
场景一:常见的配置文件key对应value
例1:我们有一个API的地址,测试环境和生成环境不一样,一般简单的做法是在Web.Config里面配置一个节点即可,但是这样做的一旦配置项过多,容易造成Web.Config臃肿,特别在生产配置时候,容易产生出错的几率,影响全局。使用“系统配置表”可以很好解决这个问题。
1.进入“系统配置文件”页面,新增一个子节点。节点名称:“接口地址”,节点代码:“qwf.demo.api”,节点代码是一个唯一主键(key),不能重复,在调用的时候需要用到,配置上节点值:“http://192.168.1.1/api”,还以写上备注:如下图:
在代码中调用:
//== 根据节点代码调用单个配节节点的值
ConfigItem item = ConfigServices.GetInstance().GetSingleNodeItemByCode("qwf.demo.api");
string value = item.Value;//节点值
string name = item.Name;//节点名称
int id = item.Id;//节点ID,是个自增ID,一般不使用
如果在发布在生产环境后,修改节点的值即可,一般来说,我们先在生成环境配置好相应的节点,然后发布程序,这样发布代码时候,可以无缝对接!。
例1的扩展:如果这个API的地址,发生变化,需要账号和密码才能访问,如何扩展呢?,其实可以直接点,简单粗暴存储一小段JSON即可^_^,就可以不用单独建立配置项目,减少冗余配置。
直接修改节点值修改成Json ,为了方便演示,我重新建立一个节点
后台代码演示:
//== 演示扩展后的节点值,存储JSON格式字符 string json = ConfigServices.GetInstance().GetSingleNodeItemByCode("qwf.demo.api.json").Value; //这里使用的是litJson解析的JSON,你可以使用自己熟悉的JSON组件解析 LitJson.JsonData jd = LitJson.JsonMapper.ToObject(json); string url = jd["url"].ToString(); string userName = jd["userName"].ToString(); string passWord = jd["passWord"].ToString(); //.....你的业务逻辑
如果有很多个这样不同的接口,我们就可以对些接口节点做个一个归类,方便后期的维护,例如:建立一个节点“项目接口API”,如下图:
场景二:常见的业务类型配置(产品分类,用户类型)
例2:产品分类,用户类型,用户来源,对产品分类分类演示,其实和例1类似,如下图:
建立以个产品分类节点: 家电类,生活用品类,图书类,节点代码:"qwf.demo.product.class"如下图:
2.在产品分类下,建立具体分类的子点,设置每个值,即可,如图:
后台代码调用:
//演示调用单个分类的Key => values 集合 List<ConfigItem> list = ConfigServices.GetInstance().GetNextNodeItemsByCode("qwf.demo.product.class"); //绑定到DropDownList 控件上 this.ddlProducts.DataSource = list; this.ddlProducts.DataValueField = "Value"; this.ddlProducts.DataTextField = "Name"; this.ddlProducts.DataBind(); this.ddlProducts.Items.Insert(0,new ListItem("==全部==", "0"));
场景3: 自定义直接的省份,地市,区域
例3: 一般来说项目中的省份、地市,区域,通常和网上下载的是有区别,为了配合实际业务需要我们通常会自定义一套适合业务逻辑的地区配置表
如下图所示:
对于这样的结构,就是一个典型的Tree结构,只要配置节点代码,就可以获取,单个节点或整个节点的值。
例如:
1.获取广东下面的地区,配置一个qwf.demo.area.gd就可以获取深圳和广州的节点信息
2.如果是做多级联动菜单和复杂业务逻辑, 可以自己编写SQL语句实现,不通过调用接口方式.具体表结构会在后面整理发出
总结:
1.节点代码是标示节点信息的只唯一的主键,推荐的命名方式为,项目名称.模块名称.业务逻辑名称
2.可以根据不能功能项和模块进行一些归类,方便后期维护和整理配置
3.系统配置表是个树形结构,可以灵活发挥。可以根据节点代码,获取单个节点值和获取当前节点下一级的节点集合,也可以通过自己编写SQL来实现自定义的业务规则
4.对于复杂的层次结构,可以直接通SQL语句关联业务数据,做高级的扩展。
5.通过可视化的界面配置,减少发布环节和后期维护的出错的几率。专注做业务逻辑页面的开发,减少重复劳动,调高生产效率