php框架中分离出service层有必要么

作者: Note 分类: YII框架学习 发布时间: 2017-03-20 13:37

在我接触过得大多数项目中都是用框架中的mvc模式进行开发,用了很长时间没有感觉有啥问题,来到这家公司后,同事说如果项目逻辑复杂可以把单独领出来写,在service层理处理逻辑,model里只处理对表查询的逻辑,一开始觉着没有必要,但是开发中感觉用service来写还是很方便,而且代码逻辑清晰,如果真的是逻辑比较复杂的话可以这样做。

下面是摘自网上对service的理解

在简单的系统里面,分层是这样的

controller <-> model <-> storage(sql、nosql、cache)

所有的业务逻辑都在model上

现在讨论一个常见的场景,用户下订单要买点东西,这个业务逻辑涉及到的model类有User(用户)、Order(订单)、Goods(商品)

那么下订单这个事情是放到User还是Order上?无论放在User还是Order上,这个业务逻辑都需要多个model类的参与

这种需求在系统里面越来越多,你就会发现你总有那么几个model在不断的膨胀,这些model之间甚至产生了网状的相互依赖关系

需求越复杂,你越容易陷入这种混乱的局面

service层的作用就是把这些需要多个model参与的复杂业务逻辑单独封装出来,这些model之间不再发生直接的依赖,而是在service层内协同完成逻辑

service层的第一个目的其实就是对model层进行解耦

业界对前面提到的那种不断膨胀的model称为“充血模型”,起初对充血模型进行反思的一种解决方案就是“贫血模型”,model里面尽量少放点逻辑,把这些逻辑都移动到controller层面去处理,在controller里面调用多个model完成业务逻辑,也达到了对model间解耦的作用

但问题就是,业务逻辑都放到controller层面了,如果其它的controller也需要相同的业务逻辑时,只能在controller里面调用其它的controller,这样做既不方便又麻烦

所以后来还是把这种解耦单独放一层,叫service,现在分层就变成这样

controller <-> service <-> model <-> storage

service层的第二个作用就是重用

差不多就是这样

简单粗暴的总结来说,如果你的某个业务逻辑,需要用到多个model,就放到service层里面去,如果只是这个model自己的事,跟其它的model没有任何关系,就放到model里面就好。

如果你的系统本来就很小,业务逻辑也超级简单,也不存在长期演进迭代的需求,随你怎么高兴怎么写都行

如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!

发表评论

电子邮件地址不会被公开。 必填项已用*标注

32 − 23 =