统一配置器框架

[禽兽v5]

构思了很久，写了一小部分，10月份继续写，这两天挺郁闷的，算是分散一下注意力吧。


1.原因与目的
由于在各种项目中存在各种不同类型的配置，一般会设计成xml和对应的解析器,但每个工具(开源或私有)对配置器的封装都不相同，造成学习成本很高，api风格多样和难以管理的问题,且其中有很多的重复编码,因此需要一个统一的配置器减轻编写配置器的负担。
比如struts的配置文件struts-config.xml很经典了，hibernate的hibernate.cfg.xml，spring的配置器等等。

因为改过hibernate代码，知道他内部是两套配置器，Configurations一套，SessionFactory一套，感觉不是好的设计。

本质上来说，配置的文件内容倒可以很多样，比如xml,json,数据库都可以，当然到了内存中一般都是对象了。
本系统最好由一个具备反射库的语言编写，比如java,python,php,ruby,delphi等。

2.系统结构

2.1配置器
Configuration Tool,比如有表单(form)，对象-关系映射(o/r m)模块，菜单(menu)，这些子系统都需要各自的配置器。配置器不可同名。配置器可拥有0~n个配置器,那么最开始的配置器称之为根配置器。
2.2.模块
Module,每个配置器都可以包含0~n个模块，且模块可以继续包含模块，相同配置器下模块不可同名。
比如对于表单配置系统，可以有系统管理(system) 模块，工作流管理(workflow)模块等。
2.3映射
Mapping,每个配置器/模块可包含0~n个映射，相同配置器下映射不可同名。
映射指向一个包含具体的配置内容的文件，比如对于表单配置系统的映射项指向一个具体的表单配置文件，一个菜单配置的映射项指向一个包含具体的菜单项的文件。
2.4定义
Definition,指对于映射文件中不同的xml标签的实现类，比如指出简单表单标签SimpleForm的实现类，或者指出一个hibernate映射标签的class的实现类，或者菜单配置中menu标签的实现类，以此构造出内存中的对象。
另外,一个xml标签的实现类,符合POJO定义,即该类是一个持久化类，这样很方便再生成hibernate配置，实现将配置内容存到数据库中。

3.配置器生成器
原则上,每一种配置都符合DTD或者XSD,因此考虑一个工具可以根据DTD或者XSD生成对应的配置器器的基本代码,节省xx%以上的工作。
而且,统一配置器本身也符合DTD规范,因此本项目应先完成本工具,再以此生成统一配置器,再生成其他系统的配置器。

[godfather521]

顶一下 尽管能力有限 看不懂 ！
我也在郁闷呢 我的一个磁盘90G 其中有80G的数据
可因为坏了一个磁道无法打开了
EasyRecovery Professional 恢复
可怜我就160G的硬盘 没有空闲空间了！！

[禽兽v5]

是我的文字描述比较粗糙，下个星期会慢慢完善的。

[kulin3422]

dddddddd

[子陌红尘]

:)

[伍子V5]

关注

[exitzhang]

是像Spring2.0里面那种整合配置文件的概念马？

[禽兽v5]

我搜索了一下，没看到spring 2.0有这种概念，他是优化了配置文件，但并不代表整合。
http://www.javaeye.com/article/25530

我提出的这个概念，是希望根据配置数据的共通点，做出通用的专门管理配置数据的框架。你说的不错，一部分概念是整合。另外的主要目标是做到动态生成，节省开发时间;动态化，节省加载时间。

[IhaveGotYou]

up一下,应该意义不大.
ini,*.properties....搞这些配置文件的管理,还不如在里面把注释写详细些.

[禽兽v5]

呃，很不幸我本周末加班，可怜。
刚睡醒，楼上刺激了我，决定写点换换脑子。

以下是基本概念

1.配置数据，配置文件：
像ini文件，xml文件，或者windows注册表，数据库中的内容，都可以称为配置或配置数据，
我们可以将保存这些数据的文件或其他形式的称之为配置文件，或者配置持久化。

2.配置解析器：
解析配置数据的工具库，称之为配置解析器。比如java.util.Properties类就是ini文件的解析器，dom4j,jdom等则是xml文件的解析器。
解析器解析配置数据，保存到解析器支持的通用数据结构中，在内存中可以根据名称和层次获取配置的值。比如
//注意：以下代码

//java.util.Properties类
//获取ini文件中username参数对应的值:username=MyName
String username = properties.get("username");

//dom4j获取hibernate.cfg.xml中的参数值
//<hibernate-configuration>
// <session-factory>
// <property name="connection.username">system</property>

SAXReader reader = new SAXReader();

Document doc = reader.read("hibernate.cfg.xml");// 声明文档对象
List list = doc.getRootElement().element("session-factory").elements("property"); //获得所有property标签

String username;
for (Object o : list)
{
Element e = (Element)o;
if (e.attributeValue("name").equals("connection.username"))
username = e.elementText();
}

3.配置器：
对付像xml中保存的配置数据，具有多层次的特点，如果简单的用一维的变量名是体现不出来的。
如果想在用的时候再去遍历解析后的数据，像上面的例子，将会造成效率的低下。
那怎么办好呢？其实就是构造对应的类库，还原其层次。
这里的特点是：
3.1 一个标签(element)对应一个类.
3.2 一个参数(attribute)对应类的属性.
3.3 标签的文本对应类的固定属性(一般是text)
3.4 有时候，只有文本的子标签，可以定义为父标签对应的类的属性.
比如
对于hibernate的映射文件，为了方便这里用一个实例Student.hbm.xml，对应的类库结构是：
/*
源文件：Student.hbm.xml
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE hibernate-mapping
PUBLIC "-//Hibernate/Hibernate Mapping DTD 3.0//EN"
"http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd">
<hibernate-mapping>
<class name="Student" table="Student">
<id name="student_id" column="student_id" type="java.lang.Integer">
<generator class="native">
<param name="sequence">student_sequence</param>
</generator>
</id>
<property name="student_name" column="Student_Name"
type="java.lang.String"/>
<property name="student_age" column="Student_Age"
type="java.lang.Integer"/>
</class>
</hibernate-mapping>
*/
//hibernate-mapping根标签一般不定义对应类
class Clazz { // 对应class标签
String name; //对应name参数
String table; // 对应table

List properties<Property>; // 说明包含0~n个property标签

Id id; // 包含1个id标签
};

class Id {
String name;
String column;
String type;

Generator generator; // 包含1个generator标签
}

class Generator {// 对应generator标签
String clazz;
List params<Param>; //包含1~n个param标签.
}

//以此类推...


不过hibernate的配置器和我的举例是有差异的，但是写法思路是一样的。这就是我开头说过的各个工具的写法都不统一的表现。

在经典的开源项目中，涉及到xml的内容到内存中的映射，都是用和配制结构对应的类来实现的，
当然对于json,数据库表中保存的配置内容，都可以这样做。
因此定义包含以下功能的工具称之为配置器：
1.从持久化的配置数据解析到内存中，并将解析后的数据映射到对应对象
2.经过配置界面或其他方式修改对应对象的值，再持久化.

[禽兽v5]

//注意：以下代码为了示例方便尽量简单，实际使用时请加上null判断和对应的try...catch...段.

[歪嘴鱼]

jf

[YuLimin]

Schema，生成JavaBean，setter，getter了事。。。

[禽兽v5]

司令来了，蓬荜生辉。

接着再写一段：
现在有了配置器的基础定义
1.从持久化的配置数据解析到内存中，并将解析后的数据映射到对应对象
2.经过配置界面或其他方式修改对应对象的值，再持久化.

当然之前我漏了一个定义

配置类：持久化的配置数据对应的类称为配置类，他的实例称为配置对象。

司令说得没错，首先要有对应的JavaBean(配置类)，根据上面的定义，配置器还要承担：
1.衔接xml和配置双向替换的功能代码。
我觉得enhydra shark给配置类加上fromXML和toXML方法的概念不错，
下面会讲解一下我的借用。

2.管理多个配置文件的功能代码，也就是说
2.1要在内存中用一个通用容器储存多个配置文件对应的对象
2.2要有保存，删除，获取这些对象的功能代码。

我以hibernate为例来分析需要什么功能，以及扩展。
hibernate分为一个全局配置文件hiberante.cfg.xml
和多个映射文件*.hbm.xml，全局配置文件中记录所有映射文件的路径，其内容如下：
<session-factory>
<mapping file="A.hbm.xml"/><!--对应pojo类A-->
<mapping file="B.hbm.xml"/><!--对应pojo类B-->
<!--其他映射文件-->
</session-factory>
hibernate中根据ClassMapping Configuration.getClassMapping(类名)的方法可以获得持久化类xml对应的对象，
ClassMapping就是hbm.xml中class标签对应的配置类。
代码我也看过了，他就是用一个HashMap<Class, ClassMapping>来保存所有加载到内存中的配置内容。
当然，class标签和ClassMapping类的对应，hibernate是写死的，
hbm.xml的内容和ClassMapping类的转换代码也是写死的，说实在的这里代码写得挺差的。
作为一个通用配置器，这些东西都应该动态化和可配置化，因此我们在全局配置文件中就要能够配置出：
3.1 映射文件中的标签对应的配置类
3.2 配置文件到对象两者之间的转换代码的实现类
那么我们可以在session-factory标签中定义如下：
<session-factory>
<def tag="class" className="net.sf.hibernate.cfg.ClassMapping">
<transfer name="xml" className="net.sf.hibernate.cfg.ClassMappingXMLTransfer"/>
<transfer name="js" className="net.sf.hibernate.cfg.ClassMappingJSONTransfer"/>
</def>

<!--其他属性和映射标签-->
</session-factory>

这样配置器就知道class标签对应的配置类是net.sf.hibernate.cfg.ClassMapping，
有2个内容转换器。转换器我定义为符合父类
/**
转换器基类.
C 解析器解析配置文件后的数据对象(如dom4j的Element),我简称配置内容.
O 配置类.
*/
abstract class Transfer<C, O> {
/**
传入配置内容, 返回配置对象.
@param configData 配置内容
@return 配置对象
*/
public abstract static O from(C configData) throws Exception;
/**
传入配置对象，返回解析器的数据对象.
@param configObject 配置对象
@return 配置内容
*/
public abstract static C to(O configObject) throws Exception;
}

这是一个IOC的方式，这样就可以很方便的给各种类型的配置文件添加转换器。
上面的例子有两个转换器，一个是xml格式的，一个是json格式的，还可以考虑其他格式，比如数据库格式等。
定义完def和transfer后，配置器管理类(比如hibernate中的net.sf.hibernate.cfg.Configuration)
的通用化就比较明朗了。

今天就到这里，累了。

[禽兽v5]

这是一个IOC的方式，这样就可以很方便的给各种类型的配置文件添加转换器。
----------
改为：
可以很方便的给配置器增加标签对应的配置类，和配置类对应的转换器。

[will125love]

study

[YuLimin]

等你完工后我来踩。。。

[guishuanglin]

非常不错的问题,我也来顶

[koj5201314]

学习 虽然有点难看懂~~~