MDA模型定义及扩展
Tiny框架中，对模型本向没有任何强制性约束，也就是说你可以把任何类型的对象作为模型，也不必实现任何接口。因此简单的说，你定义一个类，里面有一些描述业务属性或处理的内容，就可以说它是模型了。但是要想在引擎中跑起来，这么做显然是不够的，首先你得让引擎知道，这是个模型。这需要通过定义模型定义文件来声明出来。
复制代码
上面就是实体模型的描述文件。
上面就是实体模型的描述文件。
上面定义了实体模型的类型，中英文名称，对应的类的名字，错误展现页面，校验错误的展现页面，模型信息获取接口实现Bean，模型加载接口实现Bean。 也可以认为，这里是模型的元数据定义及其相关处理的实现。其中ModelInfomationGetter接口主要是用于给引擎获取相关信息，我们前面有讲，模型实现类本身不需要实现模型引擎的任何接口，但是模型引擎总是要获取模型的相关信息的，因此，在引擎扩展中需要提供ModelInfomationGetter的实现类来提供相关信息，这样的设计是为了避免对模型有侵入；ModelLoader接口用于载入模型文件，由于引擎不知道模型文件的格式，因此如何载入，也只能通过扩展来处理。
上面定义了实体模型修改处理的定义，在Tiny Mda引擎中，它认为一个模型上可以有若干个处理，每个处理又可以分成若干个步骤（至少需要一个）。每个步骤又分为三个处理过程（三个处理过程不是全部需要的），参数处理、服务处理、展现处理。 比如上面的修改操作，就定义了两个步骤，因为修改的处理过程是这样的：
步骤1：页面请求要对某条记录进行修改，参数处理构建了服务调用的参数，然后调用数据获取服务进行处理；服务处理之后把要修改的记录信息返回；界面展现处理显示修改界面给用户。
步骤2：页面请求提交记录修改，参数处理构建了服务调用的参数，然后调用保存服务进行处理；服务处理之后把要修改情况返回；界面展现提交用户已经修改完毕。
需要指出的是，
记录模型是指操作时针对的记录情况，一共有三种：None,Single,Multiple，分别表示，不需要记录，需要一条记录，需要多条记录。OK，从模型定义的角度来说，这些就已经完成了。
Tiny框架从来不认为，完成的东西是不需要修改的，因此，还提供了模型扩展的功能。
比如，上面的模型扩展，框架内建已经支持了增加、修改、删除、复制添加，等等处理，但是可以预想到，开发人员肯定需要别的处理，比如：Excel导出、PDF导出，图表显示等等；同时，有的开发人员会发现现有的实现并不满足需要，但是如果把原来的模型进行破坏性修改，对于开发与发布来说又会带来许多新的问题。
为此，Tiny框架提供了模型扩展及覆盖机制。
模型扩展定义文件与模型定义文件除了根标签不一样之外，其它完全一样；
如果原有模型中存在中同样的模型操作，则会被覆盖，如果原来的模型操作中不存在，则会被新增。 至此，就知道了在Tiny框架中，如何扩展新的模型类型或者已有的模型进行扩展或覆盖。
大量的处理，都是在模型扩展中完成的，那么模型引擎都完成什么事情呢？
1.模型体系定义
定义模型实现类可以是任何对象，定义模型上可以可以进行不同类型操作，定义模型的加载体系。
2.模型解释运行
由于模型上定义了各种操作，在人机交互过程中要驱动模型引擎及模型扩展的各种实现与扩展的协作运行，最终给用户完整的要机交互。
3.数据校验扩展
模型引擎定义了前面及后台数据校验的规范与规则，使得前后台数据校验都可以通过模型定义来完成，保证了前后台数据校验的一致性及有效性（众所周知，前台数据校验是不可靠的，后台数据校验提高成本的）。
4.权限控制体系
由于模型定义了各种各样的处理，实际上就会对数据进行各种影响，出于安全的考虑，必须对其中的一部分或全部进行权限控制。
- <model-define id="EntityModel" name="EntityModel" title="实体模型"
- model-class="org.tinygroup.entity.entitymodel.EntityModel"
- error-page="/model/modelError.pagelet"
- validate-error-page="/model/modelValidateError.page"
- model-infomation-getter="modelInfoGetter" model-loader-bean="entityModelLoader" model-to-bean="entity2Table">
- <model-processor-defines>
- <model-processor-define name="modify" title="修改" record-mode="Single">
- <model-processor-stage name="select" title="修改"
- service-processor="entityViewModelModifyStageSelectServiceProcessor"
- view-processor="defaultModelViewProcessor" parameter-builder="entityOperationModifyStageSelectParameterBuilder"></model-processor-stage>
- <model-processor-stage name="save" title="保存" need-validate="true"
- service-processor="entityViewModelModifyStageSaveServiceProcessor"
- view-processor="defaultModelViewProcessor" parameter-builder="entityOperationModifyStageSaveParameterBuilder"></model-processor-stage>
- </model-processor-define>
- </model-processor-defines>
- </model-define>
上面就是实体模型的描述文件。
上面就是实体模型的描述文件。
| 1 2 3 4 5 |
<model-define id="EntityModel" name="EntityModel" title="实体模型" model-class="org.tinygroup.entity.entitymodel.EntityModel" error-page="/model/modelError.pagelet" validate-error-page="/model/modelValidateError.page" model-infomation-getter="modelInfoGetter" model-loader-bean="entityModelLoader"> |
上面定义了实体模型的类型，中英文名称，对应的类的名字，错误展现页面，校验错误的展现页面，模型信息获取接口实现Bean，模型加载接口实现Bean。 也可以认为，这里是模型的元数据定义及其相关处理的实现。其中ModelInfomationGetter接口主要是用于给引擎获取相关信息，我们前面有讲，模型实现类本身不需要实现模型引擎的任何接口，但是模型引擎总是要获取模型的相关信息的，因此，在引擎扩展中需要提供ModelInfomationGetter的实现类来提供相关信息，这样的设计是为了避免对模型有侵入；ModelLoader接口用于载入模型文件，由于引擎不知道模型文件的格式，因此如何载入，也只能通过扩展来处理。
| 1 2 3 4 5 6 7 8 |
<model-processor-define name="modify" title="修改" record-mode="Single"> <model-processor-stage name="select" title="修改" service-processor="entityViewModelModifyStageSelectServiceProcessor" view-processor="defaultModelViewProcessor" parameter-builder="entityOperationModifyStageSelectParameterBuilder"></model-processor-stage> <model-processor-stage name="save" title="保存" need-validate="true" service-processor="entityViewModelModifyStageSaveServiceProcessor" view-processor="defaultModelViewProcessor" parameter-builder="entityOperationModifyStageSaveParameterBuilder"></model-processor-stage> < /model-processor-define> |
上面定义了实体模型修改处理的定义，在Tiny Mda引擎中，它认为一个模型上可以有若干个处理，每个处理又可以分成若干个步骤（至少需要一个）。每个步骤又分为三个处理过程（三个处理过程不是全部需要的），参数处理、服务处理、展现处理。 比如上面的修改操作，就定义了两个步骤，因为修改的处理过程是这样的：
步骤1：页面请求要对某条记录进行修改，参数处理构建了服务调用的参数，然后调用数据获取服务进行处理；服务处理之后把要修改的记录信息返回；界面展现处理显示修改界面给用户。
步骤2：页面请求提交记录修改，参数处理构建了服务调用的参数，然后调用保存服务进行处理；服务处理之后把要修改情况返回；界面展现提交用户已经修改完毕。
需要指出的是，
| 1 | record-mode="Single" |
记录模型是指操作时针对的记录情况，一共有三种：None,Single,Multiple，分别表示，不需要记录，需要一条记录，需要多条记录。OK，从模型定义的角度来说，这些就已经完成了。
Tiny框架从来不认为，完成的东西是不需要修改的，因此，还提供了模型扩展的功能。
比如，上面的模型扩展，框架内建已经支持了增加、修改、删除、复制添加，等等处理，但是可以预想到，开发人员肯定需要别的处理，比如：Excel导出、PDF导出，图表显示等等；同时，有的开发人员会发现现有的实现并不满足需要，但是如果把原来的模型进行破坏性修改，对于开发与发布来说又会带来许多新的问题。
为此，Tiny框架提供了模型扩展及覆盖机制。
模型扩展定义文件与模型定义文件除了根标签不一样之外，其它完全一样；
| 1 2 3 4 5 |
<model-define-extend id="entityModel"> <model-processor-defines> ..... </model-processor-defines> < /model-define-extend> |
如果原有模型中存在中同样的模型操作，则会被覆盖，如果原来的模型操作中不存在，则会被新增。 至此，就知道了在Tiny框架中，如何扩展新的模型类型或者已有的模型进行扩展或覆盖。
大量的处理，都是在模型扩展中完成的，那么模型引擎都完成什么事情呢？
1.模型体系定义
定义模型实现类可以是任何对象，定义模型上可以可以进行不同类型操作，定义模型的加载体系。
2.模型解释运行
由于模型上定义了各种操作，在人机交互过程中要驱动模型引擎及模型扩展的各种实现与扩展的协作运行，最终给用户完整的要机交互。
3.数据校验扩展
模型引擎定义了前面及后台数据校验的规范与规则，使得前后台数据校验都可以通过模型定义来完成，保证了前后台数据校验的一致性及有效性（众所周知，前台数据校验是不可靠的，后台数据校验提高成本的）。
4.权限控制体系
由于模型定义了各种各样的处理，实际上就会对数据进行各种影响，出于安全的考虑，必须对其中的一部分或全部进行权限控制。