设计模式 - MVC 扩展设计

本篇文章根据我自己学习的设计模式，整理出一套个人认为比较完备的设计模式。有很多不足的地方请多多指定

MVC

M：业务模型
M即model模型是指模型表示业务规则。在MVC的三个部件中，模型拥有最多的处理任务。被模型返回的数据是中立的，模型与数据格式无关，这样一个模型能为多个视图提供数据，由于应用于模型的代码只需写一次就可以被多个视图重用，所以减少了代码的重复性。
V：视图
V即View视图是指用户看到并与之交互的界面。比如由html元素组成的网页界面，或者软件的客户端界面。MVC的好处之一在于它能为应用程序处理很多不同的视图。在视图中其实没有真正的处理发生，它只是作为一种输出数据并允许用户操作的方式。
C：控制层
C即controller控制器是指控制器接受用户的输入并调用模型和视图去完成用户的需求，控制器本身不输出任何东西和做任何处理。它只是接收请求并决定调用哪个模型构件去处理请求，然后再确定用哪个视图来显示返回的数据。

由上可知。正在后台工作的只有M、C层，V层仅是组装数据，并不直接参与处理数据。

原型图

关系：上下级层级关系一 一对应。不可超出如图所示的层级关系访问。（如控制器不能直接去访问Factory和Model层，必须通过Service层去访问Factory层，再通过Factory层访问Model。依据设计原则：迪米特法则）

层级关系

• 控制层：业务特性代码的集合，所以具有很强业务特性的代码将放置在一层，如上图所示。
  a、如果业务特性代码只有一个地方在使用，则放置在controller层。
  b、如果业务特性代码具有公用性，如这个业务特性的代码并不在一个地方被使用，而是在很多地方都会使用，则将业务特性代码放置在BusinessService层。举例：订单积分抵扣、数据缓存等

• 服务层：具有服务公用性的代码集合。如关于数据表CURD操作（实际采用代理模式，将实际对表的操作交由下层的Factory层实现），服务特性的功能实现。
  举例：用户信息修改，用户状态冻结，转账，提现等均由这一层完成

• 工厂层：对模型层的CURD操作，用于为服务层提供相关数据及数据的时间。好处是后期做分库分表，我们仅需修改工厂层，就能同步到整个系统上。因为所有关于数据的CURD操作都在工厂层实现。

• 模型层：就是ORM层，对象映射至数据，一般由框架提供。如laravel 的Eloquent ORM，Yii2 Active Record等

• 工具层：这一层在任何地方都可以用，一般将这一层的类中所有的方法设计为static方法。在任何地方都可以使用，目的只是为各个层的实现做一个辅助。举例：求出二维数据当中某个数值之和、将多维数组当中所有的键值全部转为string类型。

一个类的设计思维

参见类的6大设计原则

AOP 面向切面编程

针对AOP编程，我只在java开发的时候有过类似的概念，那么在php中有没有这种概念及实现呢，我观察当前php生态提供的框架，如yii2，laravel等。我发现几个比较类似的功能可以实现切面编程。

• Yii2 行为：用户在执行某个动作前或是执行某个动作后会触发配置的目标方法，通过此种方式实现AOP
• laravel 中间件：类似钩子的思想，向下层放钩，在途中的某个位置（中间件层）做执行前，执行后的操作。

结合我自己的想法，我依托代理模式实现aop切面编程

控制器层由原来直接访问Service层，改为访问Middleware层。Middleware层本质只是个代理，将用户的请求再转接给Service层。但是在转接之前我们可以做xx操作，转接执行成功后做xx操作。