标签：一个个 路径 接下来 方法 art 后台管理 pause uninstall 列表项
电子商务解决方案驱动引擎ECOS
ECOS基于OSGI模型,我们称之为APP机制,所有业务需求都可以转化成一个相对独立较小的APP动态的集成到整个ECOS中,使得整个业务系统随需而建,随需而扩.
OSGI是JAVA下的一个组件化设计,其代表产 品是编辑器Eclipse,该工具生命力非常强大,可以 通过组件来扩充使其适合软件开发工艺中的各个流 程。
ECOS尝试作为一个类似OSGI的简易实现,简 化其开发成本,而不失去其灵活性。基于 ECOS的产品线发展,新的应用可以灵活的扩展原有 应用的界面和流程 。
OSGI的部署单位是Bundle, 对应在ECOS中就 是APP。其共性是具有称为“服务”的扩展接口。通过 Service机制,App之间可以扩展功能,界面,和操作 流程。而不必担心原有应用升级带来的问题。
Ecstore是是基于ECOS开发的企业级开源网上商店系统，所以要开发ecstore首先要了解Ecos架构
安装完ecstore后的目录结构，首先对目录有个初步的了解：
前面提到过Ecos是基于OSGI模型，所有业务需求都可以转化成一个相对独立较小的APP动态的集成到整个ECOS中,
使得整个业务系统随需而建,随需而扩
那么接下来就了解下Ecos的App机制
ECOS是完全由APP组成的系统,每个APP采用统一的约定组装在一起，base app是ecos的内核(kernel)。结构图如下：
可以看到安装完ecstore系统后整个app文件夹下包含了不同的app,这些app都是一个个的应用，包括了Base(底层app,内核)site(站点管理)、Desktop(后台管理)等
app机制的特性
前面了解了app的机制，如果想让这些app之间能够进行扩展功能互相调用，那么就要用到service机制了，通过 Service机制,App之间可以扩展功能,界面,和操作 流程。而不必担心原有应用升级带来的问题。
先了解三个概念：
可以这么理解service：
在ecos框架里面 可以把类封装在service 这个包里，当要用到service服务时，初始化service 调用service里面的一些方法
service机制中的两个角色：
这两个角色, 可以同时由一个app来提供供给, 当然也可以由不同app来提供供给
先来了解下供给者（创建service box,注册service）
由供给者提供可用的service
系统底层是通过两个步骤完成的
service 注册
service的注册是通过相应的app的service配置文件, services.xml来完成的
service.xml当所在app被install(安装)或update(更新)时被加载
注册实例：在service.xml下注册两个服务
接着在lib文件下编写方法：
接下来了解消费者如何去调用
消费有两种方式
1.从指定service box 中获取优先级最高的service class
通过service_box_id, 从service box中获取一个优先级最高的service class, 进行相关处理. 默认情况下, 后注册者优先级最高.
用法：
kernel::service($service_box_id);
例子：$obj = kernel::service(‘notebook_addon‘);
2.从注定service box中获取所有service class
通过service_box_id, 从相应service box中获取所有service class 进行相关处理. 默认情况下, 后注册者优先级最高.
用法：
kernel::servicelist($service_box_id);
例子：
与传统mvc模式不同的是，传统mvc 业务逻辑写在 C，而Ecos采用的是MVCL的设计模式(model-view-controller-library),为了复用，加多了个library,controller一般不放业务逻辑只做调用，增删改查的一些操作放lib
采用MVCL的优势在于: 将业务逻辑和数据库抽象层及用户界面剥离开，容易保证不写重复的代码，把不同类型的代码分开
数据模型抽象层(M)
一个model承载着着应用的数据和维护数据的规则, 在Ecos中models主要用来管理对应的数据库表的互动规则,通常情况下, 数据库中的一个表对应着一个model
视图(V)
视图代表着应用程序的界面. 在Ecos中, 视图通常为使用smarty标签的html文件, 视图的主要作用是提供数据到浏览器.
控制器(C)
控制器充当着视图和MODEL之间的胶水, 在Ecos中, 控制器处理从浏览器发起的请求, 从models中获取数据, 然后将数据传到视图呈现给用户.
业务逻辑库(L)
业务逻辑库, 完成所有的业务逻辑的处理, 通过调用models对数据进行操作, 不直接操作数据.从而将业务逻辑与数据处理隔离, 当然也包括框架本身所提供的基类
有一点要注意，model与其他框架不同的一点是加入了dbschema数据库表定义文件
通常情况下数据库的一个表会对应一个dbschema定义文件(数据库表定义文件)和一个model
那么什么是dbschema定义文件呢？
在ecos框架前，我们使用PowerDesigner来管理表结构，但是在一些项目的版本管理过程中，有时需要维护多个版本。powerdesigner的储存文件为一个单一的巨大的xml格式pdm文件。 这在进行版本的合并分支时几乎无法处理。 而在ecos，我们使用php去描述表结构有了以下几个优势：
dbschema文件有几个重要的功能
1. 描述表结构
2. 定义desktop app的列表项
例子：item.php描述的是item这个表，当我们要新建一个表或者更新一个表结构时，只需要描述或修改dbschema文件夹下的数据库表定义文件，最后通过安装，更新app，系统会自动将代码解析为sql语句，并在数据库中进行修改。
接下来了解ECOS的路由机制
下面是路由调度流程：
ECOS有三层路由：
第一层：app路由，定位到由那个app来提供路由机制
第二层：base,desktop,site 等系统默认的提供路由机制的app
第三层：静态路由（这是site路由提供的一个路由机制）
第一层app路由
主要文件：config/mapper.php
// key:‘/‘代表路由路径, value:‘desktop‘代表,提供路由类的app.
//通过路由配置取得提供路由处理的app: desktop因此系统在路由分发的时候会调用desktop_router类, 进行路由处理.
第二层 是有系统app base、site(前台)、destop（后台）提供的路由机制
base_router
系统在根据第一层路由调用对应的 router处理类的时候如果没有找到
则会默认的调用base_router
URL规则：
http://testserver/index.php/{$app_name}/{$ctl_name}/{$act_name}/{$
param_k1}/{$param_v1}/{$param_k2}/{$param_v2}/}
提供方法
gen_url 生成符合base_router的连接
dispatch 解析base_router连接的方法
desktop_router
提供ECOS后台的路由机制
URL规则
http://localhost/ecstorebugfix/ index.php/shopadmin/#app={$app_name}&ctl={$ctl_name}&act={$act_name}&p{$aram}={$value}
提供方法 gen_url 生成符合desktop_router的URL dispatch 解析desktop_router连接的方法
site_router
提供ECOS前台的路由机制 默认URL规则 1) http://localhost/ecstore-bugfix/index.php/brand-showlist.html 2) http://localhost/ecstore-bugfix/index.php/brand-2.html
注：该学习记录是本人在官方文档学习的基础上记录的笔记，官方文档地址：http://doc.ec-os.cn/doc/ecos/framework-ecos/index.html
标签：一个个 路径 接下来 方法 art 后台管理 pause uninstall 列表项
原文地址：https://www.cnblogs.com/ygtup/p/9719825.html
