MDA模型定义及扩展

Tiny框架中,对模型本向没有任何强制性约束,也就是说你可以把任何类型的对象作为模型,也不必实现任何接口。因此简单的说,你定义一个类,里面有一些描述业务属性或处理的内容,就可以说它是模型了。  但是要想在引擎中跑起来,这么做显然是不够的,首先你得让引擎知道,这是个模型。这需要通过定义模型定义文件来声明出来。

  1. <model-define id="EntityModel" name="EntityModel" title="实体模型"
  2. model-class="org.tinygroup.entity.entitymodel.EntityModel"
  3. error-page="/model/modelError.pagelet"
  4. validate-error-page="/model/modelValidateError.page"
  5. model-infomation-getter="modelInfoGetter" model-loader-bean="entityModelLoader" model-to-bean="entity2Table">
  6. <model-processor-defines>
  7. <model-processor-define name="modify" title="修改" record-mode="Single">
  8. <model-processor-stage name="select" title="修改"
  9. service-processor="entityViewModelModifyStageSelectServiceProcessor"
  10. view-processor="defaultModelViewProcessor" parameter-builder="entityOperationModifyStageSelectParameterBuilder"></model-processor-stage>
  11. <model-processor-stage name="save" title="保存" need-validate="true"
  12. service-processor="entityViewModelModifyStageSaveServiceProcessor"
  13. view-processor="defaultModelViewProcessor" parameter-builder="entityOperationModifyStageSaveParameterBuilder"></model-processor-stage>
  14. </model-processor-define>
  15. </model-processor-defines>
  16. </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.权限控制体系

由于模型定义了各种各样的处理,实际上就会对数据进行各种影响,出于安全的考虑,必须对其中的一部分或全部进行权限控制。

时间: 2024-08-30 11:01:34

MDA模型定义及扩展的相关文章

Entity Framework 6 Recipes 2nd Edition(11-4)译 -&gt; 在”模型定义”函数里调用另一个”模型定义”函数

11-4.在”模型定义”函数里调用另一个”模型定义”函数 问题 想要用一个”模型定义”函数去实现另一个”模型定义”函数 解决方案 假设我们已有一个公司合伙人关系连同它们的结构模型,如Figure 11-4所示: Figure 11-4. A model representing the associate types in a company together with the reporting association 在我们的虚拟的公司里, , team members被一个team lea

Entity Framework 6 Recipes 2nd Edition(11-2)译 -&gt; 为一个”模型定义”函数返回一个计算列

11-3. 为一个”模型定义”函数返回一个计算列 问题 想从”模型定义”函数里返回一个计算列 解决方案 假设我们有一个员工(Employee)实体,属性有: FirstName, LastName,和BirthDate, 如 Figure 11-3所示. Figure 11-3. An Employee entity with a few typical properties 我们想要创建一个”模型定义”函数,让它返回FirstName 和LastName 合并后的full name . 我们想

Entity Framework 6 Recipes 2nd Edition(11-5)译 -&gt; 从”模型定义”函数返回一个匿名类型

11-5. 从”模型定义”函数返回一个匿名类型 问题 想创建一个返回一个匿名类型的”模型定义”函数 解决方案 假设已有游客(Visitor) 预订(reservation)房间(hotel ) 的模型,如Figure 11-5所示. Figure 11-5. A model for hotel reservations 想要返回每位游客房间预订条数和带来的总收入.因为很多地方需要这些信息,所以想要创建一个”模型定义”函数,接受一个查询参数,返回一个包含游客合计信息的匿名类型的集合: 2. 把Li

Entity Framework 6 Recipes 2nd Edition(11-1)译 -&gt; 从“模型定义”函数返回一个标量值

第11章函数 函数提供了一个有力代码复用机制, 并且让你的代码保持简洁和易懂. 它们同样也是EF运行时能利用的数据库层代码.函数有几类: Rowset Functions, 聚合函数, Ranking Functions, 和标量值函数. 函数要么确定,要么不确定.当用一些指定的值调用函数,而函数返回的结果总是一样时,它就是确定的函数.当甚至用同样的一些值调用时,而函数每次返回的结果也可能不一样,它就是不确定的函数. 在前七小节,我们探讨“模型定义”的函数,这些函数允许我们在概念层上创建.这些函

beego——模型定义

复杂的模型定义不是必须的,此功能用作数据库数据转换和自动建表 默认的表名规则,使用驼峰转蛇形: AuthUser -> auth_user Auth_User -> auth__user DB_AuthUser -> d_b__auth_user 除了开头的大写字母以外,遇到大写会增加 _,原名称中的下划线保留. 自定义表名 type User struct { Id int Name string } func (u *User) TableName() string { return

flask中常见的关系模型定义

flask中常见的关系模型定义一对多应用场景:角色与所属于该角色的用户(角色表与多用户表) [Python] 纯文本查看 复制代码 ? 01 02 03 04 05 06 07 08 09 10 class Role(db.Model):     __tablename__ = 'roles'     id = db.Column(db.Integer, primary_key=True)     name = db.Column(db.String(64), unique=True)     

thinkphp 模型定义

模型定义 模型类并非必须定义,只有当存在独立的业务逻辑或者属性的时候才需要定义. 模型类通常需要继承系统的\Think\Model类或其子类,下面是一个Home\Model\UserModel类的定义: namespace Home\Model; use Think\Model; class UserModel extends Model { } 模型类的作用大多数情况是操作数据表的,如果按照系统的规范来命名模型类的话,大多数情况下是可以自动对应数据表. 模型类的命名规则是除去表前缀的数据表名称

ThinkPHP模型定义

模型类一般位于项目的Lib/Model 目录下面,当我们创建一个UserModel类的时候,其实已经遵循了系统的约定.模型类的命名规则是除去表前缀的数据表名称,采用驼峰法命名,并且首字母大写,然后加上模型类的后缀定义Model,例如: 模型名(类名) 约定对应数据表(假设数据库的前缀定义是 think_) UserModel think_user UserTypeModel think_user_type 如果你的规则和上面的系统约定不符合,那么需要设置Model类的数据表名称属性. 在Thin

django 模型-----定义模型

定义模型 在模型中定义属性,会生成表中的字段 django根据属性的类型确定以下信息: 当前选择的数据库支持字段的类型 渲染管理表单时使用的默认html控件 在管理站点最低限度的验证 django会为表增加自动增长的主键列,每个模型只能有一个主键列,如果使用选项设置某属性为主键列后,则django不会再生成默认的主键列 属性命名限制 不能是python的保留关键字 由于django的查询方式,不允许使用连续的下划线 定义属性 定义属性时,需要字段类型 字段类型被定义在django.db.mode