在Service层反射调用其他Service层的方法 , 却发现原先@Autowired注入的Dao层为null

原创

已于 2024-06-07 16:26:58 修改 · 1.2k 阅读

0 ·

CC 4.0 BY-SA版权

文章标签：

#其他 #spring #java

于 2022-02-09 17:25:48 首次发布

本文探讨了在Spring环境下，Service层通过反射调用其他Service层方法时，@Autowired注解失效的问题。原因是反射创建的对象未被Spring容器管理。解决方案是通过工具类获取Spring Bean，确保对象在容器内，从而保证依赖注入正常工作。示例代码展示了修改前后的对比，以及如何正确地从容器中获取并调用方法。

问题：

在Service层反射调用其他Service层的方法 , 调试时发现原先@Autowired注入的Dao层为null。

原因：

这是因为反射获得的类没有交给Spring容器管理，以至于@Autowired失效。

修改前的代码：

private String getResult(String methodParam, String methodName) throws Exception {
   
   
    Class<BatchWaybillServiceImpl> bat

最低0.47元/天解锁文章

确定要放弃本次机会？

福利倒计时

: :

立减 ¥

普通VIP年卡可用

立即使用

Percep_gan

关注关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
2
评论
分享

复制链接

分享到 QQ

分享到新浪微博

扫一扫
举报

举报

专栏目录

反射机制——通过反射调用service中方法

东天里的冬天

05-28

8384

需求：现在有一群service接口，有同一个方法名称，内部逻辑除了调用不同的调用自身的方法外其他基本都一致，那现在就需要一个独立的方法来勾勒出这个方法 1.SpringContextUtil package com.XXX.report.util; import org.apache.log4j.Logger; import org.springframework.beans.BeansE...

springboot-利用反射调用service层方法从Excel读取数据写入数据库报错：java.lang.NullPointerException，小坑一个

java web

03-24

777

springboot-利用反射调用service层方法从Excel读取数据写入数据库报空指针异常的处理方法

2 条评论您还未登录，请先登录后发表或查看评论

2 条评论

朝思暮想51 2024.06.07
这个popBean是啥
- Percep_gan回复朝思暮想51 2024.06.07
  是getBean，已改正，方法体可点击结尾链接查看

Spring service中的方法互相调用问题

weixin_44815852的博客

02-20

6646

service中的方法互相调用问题 service的方法互相调用问题分为：调用该service的方法调用其他service的方法一、调用该service的方法 spring的事务管理使用AOP实现的 AOP实现原理是递归调用所有加强方法，最后调用被代理对象的方法如果调用该service对象的其他方法，其this对应的就是被代理对象，也就是没有加强方法，其配置的事务管理是不会开启的，只能依靠调用它的方法来开启事务。二、调用其他service的方法原理同上，但是该service对象应用

摊牌了，我要手写一个RPC

程序员小潘

10-18

1万+

文章目录前言需要解决的问题手写RPC实战1、定义通信协议2、自定义注解3、定义接口4、实现接口5、暴露服务并监听处理请求6、生成RPC动态代理对象7、消费者注入RPC动态代理对象功能测试尾巴前言 RPC是远程过程调用（Remote Procedure Call）的缩写形式。SAP系统RPC调用的原理其实很简单，有一些类似于三层构架的C/S系统，第三方的客户程序通过接口调用SAP内部的标准或自定义函数，获得函数返回的数据进行处理后显示或打印。随着微服务、分布式的大热，开发者慢慢趋向于将一个大的服务拆分

springboot中利用java反射调用Service，注入Dao接口为null

超级无敌皮皮超的博客

05-10

6847

1、反射简介反射机制是在运行状态中，对于任意一个类，都能够知道这个类的所有属性和方法；对于任意一个对象，都能够调用它的任意一个方法和属性；这种动态获取的信息以及动态调用对象的方法的功能称为java语言的反射机制。 2、问题：在项目中打算做一个通用的导出方法，但是这个方法是写在一个普通的工具类中的，这个工具类中我们通过使用反射的方法去调用其他的service层，通过service层插入数据库实体对象，但是serviceImpl中的dao接口对象却为空。经过调查由于使用反射，导致dao注入失败。原因是自

详解SpringBoot 多线程处理任务无法@Autowired注入bean问题解决

08-25

在 SpringBoot 应用程序中，我们通常使用 @Autowired 注入 bean，以便在 Controller、Service、Dao 等层次中使用。但是在多线程处理任务中，当我们使用 @Autowired 注入 bean 时，会出现空指针异常。这是为什么呢？ ...

controller层@autowired注入为null问题

sinat_41913348的博客

10-18

4992

controller层@autowired注入为null问题现象：自己在里面写的test方法测试的。在controller层调用service的方法时，报了空指针异常。刚开始以为是调用jpa出错了的原因。后面慢慢发现是根本就没有注入进来。现象如下图：在网上找了些文章看了，原来是我的test方法没有将相应的对象注入。刚开始是在@test，直接将controller类new出来。改成下图注入，...

解决 SpringMVC 非spring管理的工具类使用@Autowired注解注入DAO为null的问题

炒鸡加倍

05-16

5175

有时候在工具类中需要要操作数据库，即需要注入springMVC中的DAO层，但是此时工具类并非spring管理，所以使用@Autowired注入会报空指针异常，在试了好多方案都不行时，找到了比较适合springMVC的解决方法：（1）在配置文件（springmvc.xml）中加入工具类所在包的扫描配置。（2）使用@Component注解将工具类声明为spring组件，并静态初始化。代码截取：@Co...

非controller使用@Autowired注解注入为null问题(如工具类，拦截器）

singheart的博客

04-27

1498

出现场景如下场景一、工具类一般都是静态方法，但是静态方法没办法使用容器注入的对象。知识点：静态方法：要求该属性也要是静态的，Spring/SpringBoot正常情况下不能支持注入静态属性场景二、这个类是被new出来的实例。知识点：new 过的对象不会交给容器，里面的 service或者dao注入不进来。一般是指引用某些框架，你是继承某个接口，但是这些框架默认new过这个方法，比如MVC拦截的HandlerInterceptor类。以上可以说是在项目中遇到的问题，比如项目中遇到的难点或者问题 @

一个service调用其他的service

我是一只猫的博客

07-25

4610

spring 通过反射调用service方法

热门推荐

11-16

2万+

首先介绍一下一下spring ReflectionUtils方法 org.springframework.util.ReflectionUtils 是spring提供的反射工具类，使用它有以下好处：我们在使用Java反射的时候，需要处理大量的IllegalAccessException，而这个异常，我们在业务逻辑当中，绝大多数情况都不需要捕获，使用Spring工具类，可以直接将其转换为R

Spring@Autowired自动注入Dao，取出为null

D1124615130的博客

02-21

2176

造成这种原因的一种情况。 @Service public class Test { @Autowired UserDao userDao; public int getCoins() { return userDao.getCoins(1); } public static void main(String[] args) throws SQLException { Test t...

spring 反射调用 service方法，service注入的成员变量为null

qq_38130280的博客

03-26

2178

如题，代码如下 Class<? extends BeehiveCacheService> aClass = ContextLoader.getCurrentWebApplicationContext().getBean(BeehiveCacheService.class).getClass(); aClass.getMethod(types.get(0),String...

java web:使用反射简化service方法中对业务方法的调用

qq_38971534的博客

09-01

617

在原生的web中，我们要重写HttpServlet中的doGet()或者doPost()方法来实现对url的拦截和处理。我们通常在前端中action="url?method=methodName"来把多个url请求放到同一个servlet中拦截。 package com.igeekhome.ebuy.web.servlet; import com.igeekhome.ebuy.pojo.Admin; import com.igeekhome.ebuy.service.AdminService; .

Spring事务处理时自我调用的解决方案及一些实现方式的风险

weixin_34388207的博客

09-01

187

前些日子一朋友在需要在目标对象中进行自我调用，且需要实施相应的事务定义，且网上的一种通过BeanPostProcessor的解决方案是存在问题的。因此专门写此篇帖子分析why。 1、预备知识 aop概念请参考【http://www.iteye.com/topic/1122401】和【http://jinnianshilongnian.iteye.com/blog/1418596】 spr...

微服务系统中，service层对其他服务service的调用

weixin_68247028的博客

08-04

1455

service层对其他服务service的调用

@Autowired注入之后为null

hmmmmm2929的博客

09-11

3219

使用场景: 在serviceImpl中需要调用一个工具类来转换返回的数据类型,但是在工具类中需要调用dao层的方法来查询数据因此在工具类中的方法就不能使用静态的了,并且使用了@Autowired注解来注入dao层,但是打断点的时候发现注入的dao层对象是null 经过下述步骤来寻找问题: 1.判断dao层是否加了注解或者继承JPA的一些接口 2.启动类的包扫描没有问题(spring...

@Autowired 注入为null 的原因与解决方式

weixin_42826932的博客

01-05

1万+

我们经常会通过@Autowired注解将某个类注到另一个类中，但是会发现注不进去，报NULL。可能的原因有一下几种：（1）该类没有托管给spring 管理一般在类的上面添加@Component就可以了（2）你的这个类有被new出来的实例的，new 过的对象不会交给Spring容器管理所以里面的 service或者dao注入不进来。一般是指引用某些框架，你是继承某个接口，但是这些框架默认new过这个方法，比如MVC拦截的HandlerInterceptor类。

Spring事务嵌套机制

sun82111的专栏

07-10

1万+

Spring 事务机制回顾 Spring事务一个被讹传很广说法是：一个事务方法不应该调用另一个事务方法，否则将产生两个事务.结果造成开发人员在设计事务方法时束手束脚，生怕一不小心就踩到地雷。其实这是不认识Spring事务传播机制而造成的误解，Spring对事务控制的支持统一在TransactionDefinition类中描述，该类有以下几个重要的接口方法： int ge...

Java service 方法中调用其他service和直接调用dao 如何选择

最新发布

11-23

<think> 我们正在讨论的是在Java的Service层中，应该调用其他Service的方法还是直接调用DAO层的方法。根据引用内容，我们可以总结以下几点： 1. 引用[1]提到，Service层直接调用DAO层可能会违背MVC模式的概念，增加代码耦合性。如果直接调用DAO，那么业务逻辑处理应该放在哪里？如果写在DAO层，当业务需求改变时，可能需要修改DAO，增加工作量，且代码重用性不高。因此，建议Service层调用其他Service层。 2. 引用[2]和引用[3]提到了在非Spring管理的地方（如Servlet、main方法）调用DAO或Service的问题，这提醒我们调用关系应该是在Spring容器管理的Bean之间进行，通常通过依赖注入实现。 3. 引用[4]展示了一个在Service层通过反射调用其他Service方法时遇到的问题：由于通过反射创建Service实例（new BatchWaybillServiceImpl()）而不是由Spring容器管理，导致其中注入的DAO为null。这进一步说明了应该通过Spring容器来管理Bean之间的依赖关系。根据上述引用和实际开发规范，我们可以得出以下结论： - 在Service层中，应该优先调用其他Service的方法，而不是直接调用DAO。因为Service层是业务逻辑的封装，一个业务操作可能涉及多个数据表的操作，而这些操作可能已经封装在其他Service中。直接调用其他Service可以复用业务逻辑，避免代码重复，并且符合分层设计原则（Service层依赖于其他Service层，而不是直接依赖DAO层）。 - 直接调用DAO层的情况：当当前Service需要执行一个非常简单的数据访问操作，且该操作没有在其他Service中封装，或者该操作仅与当前Service的DAO相关，且不涉及其他业务逻辑时，可以直接调用自己的DAO。但是，需要注意的是，如果在一个Service中调用另一个Service的方法，要特别注意事务的传播行为。Spring的事务管理是基于AOP代理的，在同一个类中调用另一个方法（即使是事务方法）是不会触发事务的。因此，如果两个Service方法需要在同一事务中，应该将它们放在同一个Service类中，或者通过注入自身代理（使用AopContext）来调用，但更推荐将事务方法放在不同的Service中，并通过Spring的事务传播机制来控制。总结选择方法： 1. **调用其他Service的情况**: - 需要复用其他Service中已经存在的业务逻辑。 - 操作涉及多个数据表，且这些操作已经被其他Service封装。 - 需要确保跨多个Service的操作在同一个事务中（通过声明式事务管理）。 2. **直接调用DAO的情况**: - 当前Service需要执行简单的CRUD操作，且这些操作不涉及其他业务逻辑。 - 当前Service的DAO方法仅被当前Service使用，且没有复用价值。另外，要避免在Service层中绕过Service直接调用其他Service的DAO（即调用其他模块的DAO），因为这破坏了模块的封装性，会导致代码高度耦合。因此，在编写Service方法时，应优先考虑调用其他Service，只有在上述直接调用DAO的情况满足时，才考虑直接调用自己的DAO。相关问题： 1. Service层中调用其他Service和调用DAO层的主要区别是什么？ 2. 在Service层中直接调用DAO层有哪些潜在的风险？ 3. 如何确保在Service层调用其他Service方法时的事务一致性？ </think> 在 Java Service 方法中，选择调用其他 Service 还是直接调用 DAO，需要根据业务场景和架构规范综合判断。以下是决策依据和最佳实践： ### 一、优先调用其他 Service 的场景 ✅ 1. **存在业务逻辑复用** - 当目标操作已封装业务规则（如订单状态校验、库存扣减等）时，应调用对应 Service - 示例：支付服务需调用订单服务的 `validateOrderStatus()` 方法[^1] ```java // PaymentService.java @Autowired private OrderService orderService; // 注入其他Service public void processPayment(Order order) { // 调用其他Service的业务方法 orderService.validateOrderStatus(order); // ...支付逻辑 } ``` 2. **需要事务跨表操作** - 当操作涉及多个数据表的原子性变更时，通过 Service 层保障事务一致性 - 反例：直接调用多个 DAO 可能导致部分成功/部分失败 ```java // 正确：通过OrderService管理事务 @Transactional public void createOrder(Order order) { orderDao.insert(order); inventoryDao.deductStock(order.getItems()); // 在同一个事务中 } ``` 3. **遵循分层架构原则** - Service 层应作为业务逻辑的协调层，DAO 层仅负责基础数据访问[^1] - 架构关系：`Controller -> Service A -> Service B -> DAO` ### 二、可直接调用 DAO 的场景 ⚠️ 1. **简单数据操作** - 当仅需基础 CRUD 且无业务规则时（如根据ID查询用户） ```java // UserService.java @Autowired private UserDao userDao; // 直接注入DAO public User getUserById(Long id) { return userDao.selectById(id); // 直接调用DAO } ``` 2. **私有数据访问** - 当数据操作仅限当前 Service 内部使用，无需跨服务复用时 ### 三、核心决策原则 1. **避免层级穿透** ▸ 禁止 `Service A → DAO B`（跨模块直连） ▸ 应改为 `Service A → Service B → DAO B`[^1] 2. **事务边界控制** ```mermaid graph LR A[Service方法] -- 需要跨表事务 --> B[调用其他Service] A -- 单表操作 --> C[直接调用DAO] ``` 3. **依赖方向** ▸ 高层模块可依赖低层模块（Service→DAO） ▸ 同层模块可相互调用（Service→Service） ▸ 禁止反向依赖（DAO→Service） ### 四、典型错误案例 1. **Service 中 new 其他 Service 实例**（导致依赖注入失效）[^4] ```java // 错误：通过new创建导致@Autowired失效 OrderService orderService = new OrderService(); orderService.validate(order); // 内部DAO为null! ``` 2. **Controller 直接调用 DAO**（破坏分层架构）[^2] ```java // Servlet中错误示例 public class OrderServlet extends HttpServlet { // 无法通过@Autowired注入DAO public void doGet() { UserDao userDao = new UserDao(); // 耦合严重 } } ``` ### 五、最佳实践总结 | 场景 | 调用方式 | 原因说明 | |---------------------------|-------------------|-----------------------------| | 需要复用业务逻辑 | 其他Service | 避免逻辑重复实现[^1] | | 跨实体/跨表操作 | 其他Service | 保障事务一致性 | | 简单数据查询（单表） | 直接DAO | 减少调用链开销 | | 当前Service私有数据操作 | 直接DAO | 无需服务暴露 | | 第三方服务集成 | 专用Adapter Service | 隔离外部变化 | > 💡 **黄金准则**：将 Service 视为业务能力的提供者，DAO 视为数据机械操作者。当操作蕴含业务含义时（如“冻结账户”），必调用对应 Service；当仅是数据搬运时（如“按ID查询”），可直接调用 DAO。