怎么让自己体会到Service接口的存在？

Question

大三实习，毕业半年多，接手的都是些小项目，目前项目的中service接口的存在让我感到那么点...
蛋疼...

也许因为外包公司生存为本的原因，也是我没有接触到比较大而复杂的项目原因吧

目前的体会：

1.service接口

Controller调用service，那我要去写个service了，写完实现以后，run...

报错了...

一看，接口没有加上对应方法声明，嗯...在接口里声明对应方法...

again and again...

我想问的不是接口的作用什么的，我想问，有什么能让我在小而简的项目中体会到service接口的存在，让我觉得它还不错，而不是反而成了一种累赘？

2.Controller

只想纠结于一点：Controller是用来处理请求数据和转发请求的
但是，数据的处理往往是要根据业务来进行的，按道理讲，就要放到service方法里进行处理，那么Controller一般也就直接去调用service的方法了，这变成了Controller就只是调用service的方法而已

是不是事实大部分也是这种情况...

如果没有，能得到一个为了开发规范而规范的结论也是可以接受的，毕竟开发规范也是十分重要的

以上就是我的2个比较疑惑的地方，希望大佬分享一下见解，thx

Answer 1

我写代码一般尊崇

一切代码，框架或者规范要符合当前业务体系

没有最好的，只有最符合业务的，因为那些所谓的规范，或者是框架，也不是别人瞎想的，也正因为是我上面那句，是因为实际业务使用过程确实遇到了问题，想要避免问题，想要解决问题才会创建一些条条框框，有了这些约束才不容易犯错，才更容易更高效的实现功能

因此当你业务使用某些约束或者框架不得劲，那没啥可纠结的，按照最能提升你的工作的方式去做就可以了，因为当真正现有工作方式渐渐开始不满足你的之前的想法时，你自己就会去想办法，或者寻找现有的解决方案了

举个不好的栗子，假如我很口渴，手里有杯水，直接喝了就可以解渴，但是却要学别人先烧开，然后加入糖喝，喝了还要说，为啥这么甜（捂脸。。），因为你的需求在于止渴，那些加热加糖是解决其他人需求的方案

emmm，例子不太好吧。。。见谅，供个参考

Answer 2

这就是开发规范，把一些共用的业务逻辑写到service里面

Answer 3

其实挺鸡肋的，尤其是在小项目里面，只是一个规范。
用service接口，期望的结果是接口定义好规范，各种实现可以很方便的选择和替换，但实际开发中很少在一个完整的项目上进行扩展开发，即使扩展，大多数情况下接口也需要扩展。
我们需要修改一个service实现类，因而要修改service接口的情况远比只修改实现多得多，用接口反而影响效率，如果是小项目，完全不需要多此一举，甚至实体类也不需要。

Answer 4

对于小项目而言，公司没有代码审查的话，你写哪一层问题不大，只能说是一个规范，并且有写时候的业务代码也没办法分那么清该写service还controller层，随你自己喜好

Answer 5

1.关于service层普遍会先写接口，然后再写实现。但是我觉得这种情况并不是必须的，我们知道使用接口其实是为了业务的多态，比如发送service可能有短信，邮件等等。使用接口声明然后具体方法具体实现，很合理。但是如果某个业务只有一种形式，那完全可以省略掉接口，直接写具体类。
2.关于controller层，controller层应该是一个和外界交互的一层，业务逻辑并不包含其中。与外界交互，那么他负责的就应该是与外界交互相关的东西。比如参数校验。业务逻辑应该保持在service中

Answer 6

AOP，MVC——Spring的学习以及对CodeIgniter的反思 - QueenKing - SegmentFault 思否: https://segmentfault.com/a/11...

Answer 7

rpc 了解一下，总不能让controller去暴露服务吧