这里会显示出您选择的修订版和当前版本之间的差别。
两侧同时换到之前的修订记录 前一修订版 后一修订版 | 前一修订版 | ||
模型管理指南:模型基本概念 [2017/05/21 22:56] admin |
模型管理指南:模型基本概念 [2017/05/21 23:51] (当前版本) admin [模型的作用] |
||
---|---|---|---|
行 90: | 行 90: | ||
**这就是我们APP-Link的模型了** | **这就是我们APP-Link的模型了** | ||
+ | |||
+ | ===== App-Link中的模型 ===== | ||
+ | ---- | ||
+ | |||
+ | App-Link的模型就是这么简单,并且融合了以上两者的概念。换言之,就是**类设计和数据库表实体设计的概念二合为一**。我们这里简单暴力地来告诉各位,App-Link的模型有什么特色,以直接让你领会,什么叫二合一。 | ||
+ | |||
+ | ==== 名字 ==== | ||
+ | 名很重要,名字觉得了这个模型是做什么的。User这个名字的模型绝对不会变成单车,因此,每一个模型都有一个专属的名字,而每一个名字都是你在进行**面向对象设计中定义出来的**业务对象。 | ||
+ | |||
+ | ==== 数据表 ==== | ||
+ | 以前,我们定义类,定义数据表,基本上都是分开定义的,表不一定对的上类设计,类设计并不一定只是一张表的内容。App-Link大胆地认为,这种想法完全错误。对象的类设计分为很多种,其中有一些类就是专门装在数据库的表设计用的,这种类基本上定义了就必须和数据库表结构一致。 | ||
+ | App-Link中,将模型的类设计的概念融入表的概念,让两者揉为一体。因为每一个模型就是软件中设计的实体,这些实体必然是要有**数据存储**。 | ||
+ | |||
+ | ==== 对象属性或表字段 ==== | ||
+ | 在App-Link的模型概念中,因为数据库表和类设计的概念是二合一的!因此,在APP-Link的模型设计中,我们的模型设计需要类名和表名,当然更加需要对象属性和表字段。这两者是一样的概念。在App-Link中,我们定义了许多常用的字段类型。 | ||
+ | |||
+ | |||
+ | ===== 模型的作用 ===== | ||
+ | ---- | ||
+ | |||
+ | 在App-Link中,一切都围绕着模型来构成,模型的作用有以下几点。 | ||
+ | |||
+ | ==== 解决方案 ==== | ||
+ | |||
+ | 模型的设计,意味着你的软件世界的设计,你的软件设计有什么,就是你的软件解决方案!从软件模型的设计,我们可以基本判断出这个软件是为了解决什么问题,如我们的共享单车的设计,围绕着用户-》单车的解决方案。 | ||
+ | |||
+ | ==== 数据管理中心 ==== | ||
+ | |||
+ | 模型是软件世界中的实体,那么意味着我们必须要有一个**数据管理中心**来对这些实体数据进行管理。我们的业务模型和数据中心紧密结合,直接让数据中心对我们的模型进行它的数据的增删查改功能。 | ||
+ | |||
+ | ==== 数据交互接口 ==== | ||
+ | |||
+ | 如我们之前所说的,App-Link是作为一种数据服务后端的角色出现,因此,我们对于移动应用前端的输出就是数据!数据当然是来自于模型的数据,直接为数据交互接口服务提供模型的增删查改接口。 | ||
+ | |||
+ | ===== 总结 ===== | ||
+ | ---- | ||
+ | |||
+ | 以上,是App-Link对于模型的基本概念的描述,其实作者本人也不是专家,大家就当瞎扯一顿。重要的就是,我们像类设计,数据库实体设计那样来定义、设计我们的模型,让其有数据表的存储为我们后续的数据管理中心和数据交互接口的功能提供定义,以形成一个应用完整的后端数据服务基础功能。 | ||
+ | |||
+ | 那么,接着我们详细来了解一下模型要怎么定义以及有什么属性吧。 | ||
+ | |||
+ | ---- | ||
+ | 继续前往[[模型管理指南:模型属性|]] | ||
+ | ---- | ||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ |