因此简单的说，你定义一个类。里面有一些描写叙述业务属性或处理的内容，就能够说它是模型了。 可是要想在引擎中跑起来，这么做显然是不够的，首先你得让引擎知道。这是个模型。
这须要通过定义模型定义文件来声明出来。
- <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.权限控制体系
因为模型定义了各种各样的处理。实际上就会对数据进行各种影响，出于安全的考虑，必须对当中的一部分或所有进行权限控制。