灵活高度可扩展网站系统设计

面临的需求

实际上是一个万用网站,也即是说你不知道接下来会发生什么,你需要保证你的系统具备灵活稳健的特性,根据后续随之而来的需求进行扩充新增。设想下,最初模块之间耦合度过高,后续添加或者修改功能的时候,对于这个系统而言,是极具破坏性的。

所以解耦和至关重要。

然而对于一个无边界系统而言,业务模式并不清晰,如果单纯采用MVC或者MVP会导致功能之间耦合度太高,对维护开发工作相当不利。
而且由于弱Model的设计对于代码复用很不友好。

那么最后借鉴插件的设计思想,采用HMVC模式

几个小概念

  • 耦合 关联度,两个事物之间的关联紧密程度

几种常见的设计模式

  • MVC 全拼是Model-View-Controller, 模型-视图-控制器。业务基本由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的一个实例