spring中的依赖注入有啥用？

Posted 2023-04-13

平常在做项目的时候我没用到过依赖注入这种东西，像数据这种不都是前台传过来然后在controller中接受不就行了吗？但是我在网上学习spring时全都是在配置文件中配置，注入各种数据，不是很明白，请教各位大佬。

依赖注入是spring的的两大核心之一，也叫控制反转，他的作用是将创建对象的管理交给spring容器，以前写项目会用new people的方式来创建一个people类，现在用了spring后，可以在xml中配置，也可以用注解的方式，在class文件开始部分写下面的代码，然后在这个class文件中使用到people就可以直接用people，而不需要用new来创建了，这样也大大降低了耦合性，

数据的确还是前台传到controller里，但是你在写controller的时候是不是可以通过注解的方式创建类，而不需要new了呢？或者在调用service方法的时候，不需要再new service类了，而是直接通过注解的方式在文件头声明下，后面就 直接使用了呢？

@Resources
private People people；

参考技术A 先看一段代码
假设你编写了两个类，一个是人(Person)，一个是手机(Mobile)。
人有时候需要用手机打电话，需要用到手机的dialUp方法。
传统的写法是这样:

Java code

public class Person
public boolean makeCall(long number)
Mobile mobile=new Mobile();
return mobile.dialUp(number);



也就是说，类Person的makeCall方法对Mobile类具有依赖，必须手动生成一个新的实例new Mobile()才可以进行之后的工作。
依赖注入的思想是这样，当一个类(Person)对另一个类(Mobile)有依赖时，不再该类(Person)内部对依赖的类(Moblile)进行实例化，而是之前配置一个beans.xml,告诉容器所依赖的类(Mobile)，在实例化该类(Person)时，容器自动注入一个所依赖的类(Mobile)的实例。
接口：

Java code

public Interface MobileInterface
public boolean dialUp(long number);


Person类：

Java code

public class Person
private MobileInterface mobileInterface;
public boolean makeCall(long number)
return this.mobileInterface.dialUp(number);

public void setMobileInterface(MobileInterface mobileInterface)
this.mobileInterface=mobileInterface;


在xml文件中配置依赖关系

Java code

这样，Person类在实现拨打电话的时候，并不知道Mobile类的存在，它只知道调用一个接口MobileInterface，而MobileInterface的具体实现是通过Mobile类完成，并在使用时由容器自动注入，这样大大降低了不同类间相互依赖的关系。 参考技术B 你contoller 里面注入service 不就是依赖注入么 一个@Autowired很简单就搞定了
为什么呢？你操作数据库所需要的各种实例怎么来的 空来的？

Spring Boot 应用中服务层有啥用？

【中文标题】Spring Boot 应用中服务层有啥用？

【英文标题】：What is the use of service layer in Spring Boot applications?Spring Boot 应用中服务层有什么用？

【发布时间】：2020-02-02 15:52:42

【问题描述】：

我是 Spring Boot 新手，我正在创建一个没有 UI 的 RESTful API。

我正在考虑是否应该使用业务服务并从那里调用存储库，还是直接从我的 REST 控制器调用存储库？

【问题讨论】：

请看这个***.com/questions/46442790/…你可以从这里得到答案

感谢@PratikSherke 该链接很有用。我在发布自己的问题之前尝试寻找它，但找不到它。谢谢

【参考方案1】：

Service 层并不是 Spring Boot 独有的概念。这是一个软件架构术语，经常被称为模式。简单的应用程序可能会跳过服务层。实际上，没有什么能阻止您从控制器层调用存储库方法。

但是，我强烈建议使用服务层，因为它主要用于定义应用程序边界。服务层职责包括（但不限于）：

封装业务逻辑实现； 集中数据访问； 定义事务开始/结束的位置。

引用 Martin Fowler 的 Catalog of Patterns of Enterprise Application Architecture 中的 Service Layer pattern：

服务层从连接客户端层的角度定义了应用程序的边界及其可用操作集。它封装了应用程序的业务逻辑，控制事务并在其操作的实现中协调响应。

【参考方案2】：

关注点分离是关键：

控制器（表示层或端口）

是一个协议接口，它将应用程序功能公开为 RESTful Web 服务。应该如此，仅此而已。

存储库（持久层或适配器）

抽象持久化操作：查找（按 id 或其他标准）、保存（创建、更新）和删除记录。应该如此，仅此而已。

服务层

（域）包含您的业务逻辑。它定义了您提供的功能、访问方式以及传递和返回的内容 -

独立于任何端口（其中可能有多个：Web 服务、消息队列、预定事件）并且独立于其内部工作原理

（服务使用存储库，甚至数据在存储库中的表示方式与任何人无关）。服务层可以从存储库数据中进行 1:1 转换，或者可以应用过滤、转换或聚合附加数据。

业务逻辑一开始可能很简单，提供的只是简单的 CRUD 操作，但这并不意味着它会永远保持这种状态。一旦您需要处理访问权限，就不再需要将请求从控制器直接路由到存储库，而是还要检查访问和过滤数据。请求在访问数据库之前可能需要验证和一致性检查，可能会应用规则和其他操作，因此您的服务会随着时间的推移获得更多价值。

即使是简单的 CRUD 案例，我也会引入一个服务层，它至少可以将 DTO 转换为实体，反之亦然。

让您的控制器/存储库（或端口和适配器）保持愚蠢，让您的服务保持智能，这样您就可以获得可维护且可良好测试的解决方案。