Spring Boot中如何在自定义删除方法中使用Autowired注入Bean并解决仓库初始化失败问题

Great question! Let's break down why your current approach isn't working, then walk through a few clean, Spring-compliant solutions that fit your use case (including handling cascading deletes from parent entities).

Why Your Original Code Failed #

Spring Data JPA works by dynamically generating proxy implementations for interfaces that extend JpaRepository. Your abstract class approach bypasses this core mechanism—Spring can't properly inject the BlobContainerClient into a custom abstract implementation, nor can it create a valid repository bean from it. Let's fix that with standard Spring Data patterns.

1. Use Spring Data's Custom Repository Fragments (Official Recommendation) #

This is the cleanest, most maintainable approach, as it separates your custom logic from Spring Data's built-in repository functionality while keeping everything integrated.

Step 1: Define a Custom Repository Interface #

First, create an interface to hold your custom cleanup logic:

public interface AssetRepositoryCustom {
    void cleanUpBlobBeforeDelete(Asset asset);
}

Step 2: Implement the Custom Logic #

Write an implementation for this interface, using constructor injection (preferred over @Autowired for testability and clarity):

@Repository
public class AssetRepositoryImpl implements AssetRepositoryCustom {

    private final BlobContainerClient assetContainerClient;

    // Spring will auto-wire this constructor for you
    public AssetRepositoryImpl(BlobContainerClient assetContainerClient) {
        this.assetContainerClient = assetContainerClient;
    }

    @Override
    public void cleanUpBlobBeforeDelete(Asset asset) {
        BlobClient assetClient = assetContainerClient.getBlobClient(asset.getFileReference());
        assetClient.delete();
    }
}

Step 3: Combine with the Main Repository #

Update your main repository interface to extend both JpaRepository and your custom interface, then override the delete method to run your cleanup first:

public interface AssetJpaRepository extends JpaRepository<Asset, Long>, AssetRepositoryCustom {
    Asset findByUuid(String uuid);
    Asset findOneByFriendlyName(String friendlyName);

    @Override
    default void delete(Asset asset) {
        // Clean up the Azure Blob first
        cleanUpBlobBeforeDelete(asset);
        // Delegate to Spring Data's default delete logic
        JpaRepository.super.delete(asset);
    }
}

This works seamlessly with cascading deletes—any call to delete(Asset) (including those triggered by parent entity deletions) will execute your custom cleanup logic.

2. Use Entity Lifecycle Annotations (@PreRemove) #

If you prefer to tie cleanup directly to the entity's lifecycle, use the @PreRemove annotation. Since entities aren't managed by Spring by default, you'll need to enable Spring's @Configurable support to inject dependencies.

Step 1: Configure the Entity #

Add @Configurable to your Asset entity, and inject the BlobContainerClient (mark it transient to avoid serialization issues):

@Entity
@Configurable(preConstruction = true)
public class Asset {
    // Your entity fields (id, uuid, friendlyName, fileReference, etc.)

    @Autowired
    private transient BlobContainerClient assetContainerClient;

    @PreRemove
    public void preRemove() {
        // Runs right before the entity is deleted from the database
        BlobClient assetClient = assetContainerClient.getBlobClient(this.getFileReference());
        assetClient.delete();
    }
}

Step 2: Enable Spring Configured Support #

Add @EnableSpringConfigured to your Spring Boot main class, and include the Spring Aspects dependency:

<dependency>
    <groupId>org.springframework</groupId>
    <artifactId>spring-aspects</artifactId>
</dependency>

This ensures cleanup runs every time the entity is deleted, regardless of whether it's called directly or via cascading delete. The tradeoff is slight coupling between your entity and Spring components.

3. Use Spring Data's Entity Deletion Events #

For a fully decoupled approach, listen for Spring Data's EntityDeletedEvent to trigger Blob cleanup when an Asset is deleted.

Create an Event Listener #

@Component
public class AssetDeleteEventListener {

    private final BlobContainerClient assetContainerClient;

    public AssetDeleteEventListener(BlobContainerClient assetContainerClient) {
        this.assetContainerClient = assetContainerClient;
    }

    @EventListener
    public void handleAssetDeleted(EntityDeletedEvent<Asset> event) {
        Asset deletedAsset = event.getEntity();
        BlobClient assetClient = assetContainerClient.getBlobClient(deletedAsset.getFileReference());
        assetClient.delete();
    }
}

This listener automatically picks up all Asset deletion events (including cascading deletes) without modifying your entity or repository. It's ideal for keeping concerns fully separated.

内容的提问来源于stack exchange，提问作者Jari Vm