面临的需求

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

所以解耦和至关重要。

然而对于一个无边界系统而言，业务模式并不清晰，如果单纯采用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的一个实例