Spring中用new手动创建对象而非依赖注入是否为不良实践？IoC需管理所有对象吗？

Great question—this is one of the most common pitfalls for developers new to Spring, so let’s unpack each part of your query clearly.

1. Is Directly Using new a Bad Practice? #

Short answer: It depends on the object and its purpose. It’s not inherently bad, but it can be a mistake in certain scenarios.

• Perfectly acceptable uses of new:

  • For simple, stateless data transfer objects (DTOs) or plain old Java objects (POJOs) that hold no business logic and have no dependencies on Spring-managed beans. Example:

    UserDTO userDTO = new UserDTO("John Doe", "john@example.com");
    

  • For one-off utility objects or local variables that don’t need to be shared across components or don’t require Spring’s features (like AOP, transaction management, or lifecycle callbacks).

• Bad uses of new:

  • When creating objects that depend on other Spring-managed beans (e.g., a UserService that needs a UserRepository). If you use new UserService(), you’ll have to manually instantiate and inject all its dependencies—defeating the purpose of dependency injection (DI) and creating tight coupling between components.
  • When creating objects that need Spring’s lifecycle management (e.g., beans with @PostConstruct or @PreDestroy methods) or cross-cutting concerns (e.g., @Transactional, @Cacheable). Spring can’t apply these features to objects you create with new, since they’re not part of the IoC container.

2. Is Manual Object Creation (vs. DI) a Bad Practice? #

Again, context is key. Manual creation with new is a bad practice only when you’re bypassing Spring’s DI for objects that should be managed by the container.

DI exists to:

• Reduce coupling between components (you depend on abstractions, not concrete implementations)
• Make testing easier (you can mock dependencies instead of relying on real instances)
• Centralize object management (Spring handles lifecycle, scoping, and dependency resolution)

If you’re using new for objects that benefit from these advantages, you’re missing out on Spring’s core value. But for simple, self-contained objects, manual creation is perfectly fine and even preferred—there’s no need to clutter the IoC container with trivial beans.

3. Does the Spring IoC Container Need to Know About All Objects in the App? #

Absolutely not. The IoC container only needs to manage objects that require its services. Here’s why:

• Performance: Loading every object into the container would bloat it, slow down application startup, and waste resources.
• Flexibility: Many objects don’t need DI, lifecycle hooks, or cross-cutting concerns. Forcing them into the container adds unnecessary complexity.
• Single Responsibility: The IoC container’s job is to manage dependencies and lifecycle for beans that need it—not to track every object your app creates.

Think of it this way: The container is a tool for managing your app’s core infrastructure and business logic components. Objects like DTOs, local utility instances, or temporary data holders don’t need to be registered as beans.

Quick Recap #

• Use new freely for simple, self-contained objects with no dependencies on Spring-managed beans.
• Avoid new for objects that need DI, Spring features, or to be shared across components—register them as beans and use dependency injection instead.
• Spring doesn’t need to know about every object in your app—only the ones that benefit from being managed by the IoC container.

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