MVC模式的优化方案(1)——加入 Service 层

推荐文章 shanhuhai 3326℃ 0评论

大部分程序员都知道 MVC 的软件设计方式,但是用了这么久的设计模式,你是否发出过疑问,目前的MVC设计方式有哪些问题,还有什么样的改进空间?今天来简单介绍下。

经典的MVC设计模式,其中 M(模型)、V(视图)、 C(控制器),其中模型中放是主要的业务代码和数据库交互,视图是软件的与用户的交互界面,对于web开发来说一般就是html,css,js,控制器用来调用模型和视图去完成用户请求。

以上是标准的对MVC模式的解释,但是现实开发中我们真的遵循了MVC的架构了么,我们用的框架都是MVC的框架, 有 Thinkphp, CodeIgniter,Yii ,但是现实情况是大部分人在控制器层写了太多的业务代码,导致一个控制器的方法变的越来越难维护,为什么他们不把这些业务代码放到模型中呢,我的理解,也许是在很多的框架里,一个模型会对应一个数据表,是一一对应的关系,而且一个模型也默认继承ORM操作类,也就是说在大多数框架里,模型被定义为了表的操作类,这时候我们就会困惑,模型是这样的话,我在模型里放的业务代码应该是跟对应的表相关的才是合理的,然而我们的业务往往不是用表的种类来拆封的,这个时候写程序就会很纠结,有些代码放到模型里感觉不合适,放到控制器里又觉的累赘,这时候我们应该引入新的一层这就是我们要说的“Service(服务层)”。

给MVC添加service层

什么是服务层,“服务”这个词要跟你的实际业务结合起来思考,不同的软件决定了要提供什么样的服务,从你的业务去思考,需要什么样的服务才能满足需求,我应该把服务拆到多大的粒度。

想想如果你在银行柜台取钱,首先可能要排号,轮到你了 ,系统会呼叫你去柜台办理业务,然后业务员会帮你办理业务。银行给你提供取钱的业务,需要将三个不同的服务组合在一起才能满足你的需求,分别是取号的服务,叫号的服务,业务员办理取钱的服务。

通过将业务拆分成不同的服务,拆分时的另一个原则是服务粒度要足够小,一个服务完成一个业务功能,你会发现通过组合不同的服务,我们就能实现几乎所有的业务需求。

先讲到这里下一篇再将模型和服务层的关系。

转载请注明:大后端 » MVC模式的优化方案(1)——加入 Service 层

喜欢 (3)or分享 (0)
发表我的评论
取消评论

表情

Hi,您需要填写昵称和邮箱!

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址