服务层已过时吗？

几个月前，我与我的同事Lorenzo Dee进行了有关服务课程的对话。 “在许多情况下，您不需要它们……您只需将存储库直接注入Controller中即可。” 我很震惊！ 这是什么异端！ 这违反了关注分离！ 您的代码库将受到僵化，紧密耦合的代码的困扰，这些代码很难测试和更改！ 我和他争辩了所有这些观点……以一种比我刚刚写的更有礼貌的方式。 我们俩都无法说服对方。

洛伦佐（Lorenzo）在我们的辩论中拥有的一个优势是，他比我拥有更多的近期项目经验。 我上次向生产中的企业系统提供任何代码是在2006年。一年前我成立了Orange＆Bronze Software Labs ，很快我就忙于运营公司，以至于我无法为实际项目贡献代码。以富有成效的方式 但是，直到那时，我还是通过表示，服务和集成（或持久性）这三个应用程序层来编写项目。

为什么我们需要服务层？

可测性

我仅使用普通的旧Servlet开始进行Web开发，当时我们只有这些。 然后Struts出现了。 即使是Struts，仍然存在的问题是为了测试您的应用程序，您必须将其部署到Servlet容器中。 这使得“测试驱动开发”非常缓慢且繁琐，甚至是诸如ServletUnit或Apache Cactus之类的专用工具。

解决方案是将尽可能多的逻辑转移到不需要部署到容器的普通类中，因此可以使用普通的JUnit进行测试。 对我来说，这是服务最明显的好处之一。

生存变化

在Struts出现了框架的爆炸式增长之后，Wicket，Tapestry，Stripes，Stripe，WebWork（成为Struts 2）……框架的爆炸式增长也在持久性方面– Hibernate，JPO，Ibatis……还没有JPA标准。 想想当今的Java框架世界正在发生什么，这就是2000年代初至中期的Java框架的情况。

为了适应变化，系统的核心代码必须位于与明年可能要更改的任何特定框架无关的地方。 再次，这是服务层出现的地方。

多视图

即使在那时，您仍需要一种方法来支持多种客户端技术-HTML，桌面（Swing或Eclipse RCP），RMI，然后是更高版本的Web服务（SOAP，JSON）。 那时我们还没有视图解析器，所以我们不得不编写一个不同的Controller或编写大量的if块来处理多个视图。

同样，将其余逻辑耦合到一个特定的视图将是一场灾难，因此您需要将逻辑推到独立的层，并且各种Controller都将位于该层的顶层。 这再次证明了服务层的合理性。

发生了什么变化？

最大的变化是标准-诸如JPA的正式标准，以及诸如Spring Framework的事实上的标准。 由于标准化的原因，您现在可以在成千上万的大型企业应用程序中看到相同的技术堆栈（通常是Spring + JPA / Hibernate），通常需要十年甚至可以看到十年。 当那些技术看起来永远不会被蜜蜂取代时，与技术无关的层的经济理由就变得不那么重要了。

这些技术带来了很多好处– AOP，视图分辨率，通过注释的声明式编程，约定优于配置…如此之多，以至于今天我们发现，除了委托给其他类之外，服务层几乎无所要做– 惰性类 代码气味的定义！

我的顿悟

使我信服的是当我发现自己有一点空闲时间时。 有一个内部应用程序需要重写，但是没有开发人员有时间去做。 我决定试一试，因为我非常了解自己可能无法在再次忙之前完成。 这是我第一次使用Spring MVC ，并且在编写了我的第一个Controller之后，看到现在声明式处理了多少常规工作，这真让我震惊！

控制器现在非常薄 ，您可以将同一控制器用于多个视图 。 它们也可以用普通的JUnit进行测试 ，因为您不需要将它们部署到Container。

由于Controller和Services几乎无所事事，我的面向对象培训要求我将两者合并！

交易呢？

但是对我来说，一个问题仍然是-交易。 如果您需要事务操作，是否可以将@Transactional批注添加到Controller中？

“是的，那是我唯一一次提供服务。” 洛伦佐说。 “当我发现一项操作需要进行事务处理时，这是我创建服务的唯一时间。”

但即使那样，我现在也提出质疑。 查看关于此主题的StackOverflow讨论的答案 。 制作Controllers @Transactional似乎没有技术障碍。 这是我需要用一些代码来验证的东西，但是当我这样做时，我将发布我的发现，如果一切顺利，我将把本文的标题更改为“服务层已过时！”…没有更多的问号！

翻译自: https://www.javacodegeeks.com/2017/11/service-layer-obsolete.html