灵活高度可扩展网站系统设计
面临的需求
实际上是一个万用网站
,也即是说你不知道接下来会发生什么,你需要保证你的系统具备灵活稳健的特性,根据后续随之而来的需求进行扩充新增。设想下,最初模块之间耦合度过高,后续添加或者修改功能的时候,对于这个系统而言,是极具破坏性的。
所以解耦和至关重要。
然而对于一个无边界系统而言,业务模式并不清晰,如果单纯采用MVC
或者MVP
会导致功能之间耦合度太高,对维护开发工作相当不利。
而且由于弱Model的设计对于代码复用很不友好。
那么最后借鉴插件的设计思想,采用HMVC
模式
几个小概念
耦合
关联度,两个事物之间的关联紧密程度
几种常见的设计模式
MVC
全拼是Model-View-Controller, 模型-视图-控制器。业务基本由View处理

1 2 3 |
1. View 传送指令到 Controller 2. Controller 完成业务逻辑后,要求 Model 改变状态 3. Model 将新的数据发送到 View,用户得到反馈 |
MVP
Model-View-Presenter, 把MVC的控制器改成了Presenter展示器,
View和Model和Presenter都是双向通讯,Presenter业务过重容易崩盘
MVVM
基本和MVP一致,核心区别在它采用双向绑定(data-binding):View的变动,自动反映在 ViewModel。
HMVC
: Hierarchical-Model-View-Controller,也可以叫做 Layered MVC。顾名思义,就是按等级划分的 MVC 模式,简单的解释就是把MVC又细分成了多个子 MVC,每个模块就分成一个 MVC。
可以降低各个功能模块之间的耦合性,提高代码复用性,使得每个功能都可以独立出来,每个模块都有自己的 MVC 结构,每个控件都有自己的行为,控件之间互不影响。
一堆HMVC模块该怎么组织
细想下每个功能都是一个扩展的单独模块,文章有分类,产品有分类,
后面又来了个给文章打标签的功能,然后客户来了,所有的模块都堆积在一起,
或导致逻辑很混乱,接地气的讲,功能菜单叠在一起一塌糊涂。
为应对这种情况,所以再引入了一个Context
上下文的概念,根据谁家孩子谁负责,关系不清楚的放一堆
的原则进行分类。比如产品类别、扩展信息等等,自然归入产品菜单。至于标签这个事情,文章产品都可以有,那就单独放着了。
模块设计原则
谁引起谁负责,避免出现多对多的逻辑
这样的话可以有效避免模块之间的信息双向流动。
比如说这个样子
客户 ↓ | 产品 ↓ | 内容 ↓ |
---|---|---|
列表 | 列表 | 新闻 |
反馈 | 类型 | 活动 |
订单 | 区域 | ··· |
权限控制设计
权限管理基本是后台管理系统的一个必备内容了。
对于HMVC
来说,搭配上RBAC
,模块自行设计自己的权限,分配权是时候根据角色勾勾选选即可。
RBAC概念
RBAC
也就是基于角色的访问控制(Role-Based Access Control)。
权限与角色相关联,用户通过成为适当角色的成员而得到这些角色的权限。好理解也好用。
在一个公司里面,角色是为了完成各种工作而创造,用户则依据它的责任和资格来被指派相应的角色,用户可以很容易地从一个角色被指派到另一个角色。角色可依新的需求和系统的合并而赋予新的权限,而权限也可根据需要而从某角色中回收。角色与角色的关系可以建立起来以囊括更广泛的客观情况。
当然权限管理有好多种
ACL
Access Control List,访问控制列表。
举个例子就明白了,手机现在只有一个用户,允许微信访问照片,阻止XX软件访问网络等。这个权限管理就是ACL的一个实例