MVC从多层模型开始(原创)

架构 · huanghe · 于 2年前 发布 · 1473 次阅读

原文:http://blog.hahaxixi.cc/2017/03/03/MVC01/


如果你的控制层比模型层更大,产品同学找你改个功能很费劲,一改就来bug的时候,你可以考虑用多层模型解耦你的业务。

MVC功能定位

  1. 模型(Model)应当负责管理几乎所有涉及数据的事情,包含数据、业务逻辑,以及数据校验规则。
  2. 控制器(Controller)用来解释请求数据,使用相应的模型,并渲染相应的响应或视图,可以被看作是模型和视图之间的中间人处理动作和请求。
  3. Views包含用户界面元素,如文本、图片和表单,当然,现在流行前后端分离的架构中,这一层可能从后端同学那里剥离出去了。

数据和业务逻辑放在模型层,控制器只是个中间人的角色,这样就保持了瘦控制器和胖模型。但是实际开发中,很多同学会将数据的校验和业务逻辑放在控制器层,变成了胖控制器,瘦模型,控制层的代码没有复用性可言,产品需求一改,重构又要开始了。所以如果仅仅把模型当作数据库表的映射,一张数据库表对应一个模型是远远不够的。

分层次设计模型

  1. 多层模型的本质原因是由于数据库和业务逻辑之间的差异性,比如关系型数据库中的数据都是存在表中,以一行行数据的形式进行存取的,而程序运行却是一个个对象,实现数据的过滤,数据的处理等业务逻辑,一个对象的数据一般都对应了多张表。如果把业务处理逻辑和数据存取逻辑完全混杂在一块,甚至比把业务逻辑放在控制器里更难维护。
  2. 模型的层级:
    • 一层应该是每个模型映射一张数据表,比如一篇文章对应一个文章表,文章分类对应一个分类表,这里就是两个模型,想必大多数同学都是这样设计模型的,这里就不多说了,我这里把这个成为A层模型。
    • 一些可以复用的业务逻辑块可以封装成模型,供控制器或者模型调用,比如页面的搜索功能,可以继承最相关的A层模型,然后独立成模型,供不同页面都要这个查询功能的控制器调用。
    • 每个表单或者API需要独立的模型,这里面包含了这个表单或者API的数据校验和不可复用的业务逻辑,这个比较关键,也是本文的重点。比如注册表单或者API,需要独立的注册模型,这里面就包含了账号,验证码各种的校验,校验通过之后注册的逻辑,注册之后用户表需要添加一条数据,用户详情表也需要添加一条数据,这就对应了2个A模型,这些都只是注册特有的逻辑,独立出来做成单独的模型,这样业务修改需求主要修改这里,简单清晰。

后话

随着业务的发展,仅仅MVC这样的分层划分已经不能满足需求了,但更强大的架构本质都是抽象出更多的层级,毕竟计算机中的所有问题,都可以通过向上抽象封装一层来解决,这超过本文的讨论范围。

本文由 huanghe 创作,采用 知识共享署名 3.0 中国大陆许可协议 进行许可。 可自由转载、引用,但需署名作者且注明文章出处。

本帖已被设为精华帖!
共收到 0 条回复
没有找到数据。
添加回复 (需要登录)
需要 登录 后方可回复, 如果你还没有账号请点击这里 注册