Spring Framework Explained: IoC, Dependency Injection, Beans & MVC - A Complete Developer Guide

Spring Framework powers over 60% of enterprise Java applications worldwide. Yet despite its dominance, most developers who use it daily can't explain why it works the way it does. They know the annotations. They copy the patterns. But the moment something breaks - a bean doesn't inject, a request doesn't route, validation silently fails - they have no mental model to debug from.

This guide changes that. It explains the five foundational concepts that make Spring work: Inversion of Control, Dependency Injection, Bean management, Spring MVC's request flow, and validation with error handling. Not just what they are - but why they exist, how they connect, and exactly where they appear in real Spring code.

By the end of this guide, you'll understand not just how to use Spring but how Spring thinks. That mental model is the difference between copying Spring code and writing it with intention. If you're building your Java foundation first, Board Infinity's guide on core Java concepts and syntax is essential reading before diving into Spring - and their overview of OOP concepts in Java explains the class, interface, and object model that Spring's entire DI architecture is built on.

Who This Guide Is For

This guide is ideal for developers who:

• Know Java basics but are new to the Spring Framework
• Can write Spring Boot apps but want to understand what's happening under the hood
• Have used @Autowired and @Service but can't explain how they work
• Are preparing for Spring-related technical interviews
• Want to understand the Java interface model that makes IoC genuinely click - Board Infinity's multiple inheritance in Java guide explains how Java interfaces enable Spring's loose coupling: when OrderService declares private final UserRepository userRepo, it depends on the interface - not any specific implementation

1. What Is Inversion of Control - The Core Idea Behind Spring

Inversion of Control (IoC) is the foundational principle that Spring is built on. To understand it, you need to understand what it inverts.

In traditional Java code, you control object creation. If OrderService needs a UserRepository, you write UserRepository repo = new UserRepository() inside OrderService. You create it. You manage it. You're in control.

With IoC, you invert that control. Instead of OrderService creating its own dependencies, Spring creates them and hands them in. OrderService doesn't know or care how UserRepository was created - it just declares it needs one, and Spring provides it. The framework is now in control of object lifecycle, not your code.

This inversion has a profound consequence: your classes become loosely coupled. OrderService doesn't depend on a specific UserRepository implementation - it depends on whatever Spring injects. Swap the implementation, change the configuration, and OrderService needs zero changes. Understanding how Java interfaces enable this pattern is what makes IoC genuinely click. Board Infinity's abstraction in Java guide covers the foundational principle directly: IoC works precisely because OrderService depends on the abstract UserRepository interface, not a concrete class - abstraction is what makes the implementation swappable without touching the dependent class.

// WITHOUT IoC: tight coupling, hard to test or swap
public class OrderService {
    // You create dependencies - tightly coupled to this exact class
    private UserRepository userRepo = new UserRepositoryImpl();
    private EmailService    email    = new SmtpEmailService();
public void placeOrder(Order order) {
    // Can't swap UserRepository without editing this class
    userRepo.save(order);
}
}
// WITH IoC + Spring: loose coupling, testable, swappable
@Service
public class OrderService {
// Spring creates and injects these - you declare, Spring provides
private final UserRepository userRepo;
private final EmailService    email;
public OrderService(UserRepository userRepo, EmailService email) {
    this.userRepo = userRepo;
    this.email    = email;
    // Swap EmailService implementation in config - zero change here
}
}

2. Dependency Injection: Constructor vs Setter vs Field

Dependency Injection (DI) is the mechanism Spring uses to implement IoC - the actual way Spring hands dependencies to your classes. There are three ways to inject: constructor injection, setter injection, and field injection. They produce the same result but differ significantly in quality, testability, and safety.

With constructor injection, all required dependencies are set at object creation time and can be declared final - guaranteeing they're never null and never reassigned. With field injection, the field can't be final, dependencies can be null before Spring initialises them, and unit testing requires a Spring context or reflection hacks. The final keyword on constructor-injected fields is one of the most important access control distinctions in Spring development. Board Infinity's access modifiers in Java guide explains why private final is the correct combination: private restricts external access to the dependency, and final guarantees immutability - once Spring injects the dependency through the constructor, it can never be replaced or set to null by any code path.

// 1. CONSTRUCTOR INJECTION (recommended)
@Service
public class UserService {
private final UserRepository userRepository; // final = immutable

// Spring injects via constructor - no @Autowired needed in Spring 4.3+
public UserService(UserRepository userRepository) {
    this.userRepository = userRepository;
}
}
// 2. SETTER INJECTION (for optional dependencies)
@Service
public class ReportService {
private CacheService cacheService; // optional - may not exist

@Autowired(required = false) // won't fail if CacheService bean missing
public void setCacheService(CacheService cacheService) {
    this.cacheService = cacheService;
}
}
// 3. FIELD INJECTION (avoid - shown for recognition only)
@Service
public class OrderService {
@Autowired // directly on field - can't be final, hard to test
private OrderRepository orderRepository;
// Avoid this pattern - Spring team explicitly recommends against it
}

3. Spring Beans: Lifecycle, Scopes, and When They Matter

A Spring Bean is any object managed by the Spring IoC container. When you annotate a class with @Component, @Service, @Repository, or @Controller, you're registering it as a bean. Spring creates it, manages its lifecycle, and destroys it when the application shuts down.

Bean Scopes: The scope defines how many instances of a bean Spring creates. The two most important scopes are singleton (one instance shared across the entire application - the default) and prototype (a new instance created every time the bean is requested).

For most Spring Boot applications, the default singleton scope is exactly what you want. Services, repositories, and controllers are stateless - they don't hold user-specific data - so one shared instance works perfectly. Prototype scope is useful for beans that hold state. The List<CartItem> items = new ArrayList<>() in the ShoppingCart prototype-scoped bean is exactly why scope matters - each user session gets its own ShoppingCart instance with its own ArrayList. Board Infinity's Java List guide covers ArrayList directly: this mutable, ordered collection is safe in a prototype bean (each instance has its own list) but would be a critical concurrency bug in a singleton bean (all users sharing the same list). The singleton class in Java guide provides the foundational context - Spring's singleton scope is the same pattern as the Java Singleton, and understanding why the pattern guarantees one instance helps explain why singleton beans must be stateless.

// SINGLETON scope (default) - one instance for entire app
@Service // implicitly @Scope("singleton")
public class UserService {
    // Spring creates ONE instance - shared across all controllers
    // Safe because UserService holds NO user-specific state
}
// PROTOTYPE scope - new instance per injection point
@Component
@Scope("prototype")
public class ShoppingCart {
private List<CartItem> items = new ArrayList<>();
// New instance per user session - holds user-specific state
}
// BEAN LIFECYCLE HOOKS
@Service
public class DatabaseConnectionService {
@PostConstruct // runs AFTER Spring injects all dependencies
public void initialise() {
    System.out.println("Bean ready - connection pool initialised");
}

@PreDestroy // runs BEFORE Spring destroys the bean on shutdown
public void cleanup() {
    System.out.println("Bean shutting down - closing connections");
}
}

4. Spring MVC Flow: DispatcherServlet - Controller - View

Spring MVC is Spring's web framework for handling HTTP requests. Understanding its flow is essential for debugging routing issues, understanding where validation runs, and knowing where to add cross-cutting logic like logging or authentication.

Every HTTP request that reaches a Spring MVC application passes through the same six-step pipeline: DispatcherServlet receives the request, HandlerMapping finds the matching controller method, HandlerAdapter calls it with the right arguments, your @Controller executes, ViewResolver resolves the view name, and the response is sent back.

The DispatcherServlet at the centre of this pipeline is a Java servlet - it extends HttpServlet and processes every HTTP request. Board Infinity's understanding servlets in Java guide covers the Java servlet model that DispatcherServlet is built on: understanding how HttpServletRequest and HttpServletResponse work at the servlet level explains why Spring MVC can extract @PathVariable, @RequestParam, and @RequestBody values from incoming requests, and why the response is written back through HttpServletResponse. The @ModelAttribute ProductForm form in the createProduct() POST method also connects to Java's class model - Spring uses the Product class's setters to bind form fields to the Java object. Board Infinity's classes and objects in Java guide covers how Java objects are instantiated and their fields set through constructors and setters - the same mechanism Spring's data binding uses to populate @ModelAttribute and @RequestBody objects from HTTP request data.

// DispatcherServlet is auto-configured by Spring Boot
// It intercepts ALL requests to your application
// Step 4 - Your controller handles the request
@Controller
@RequestMapping("/products")
public class ProductController {
private final ProductService productService;

public ProductController(ProductService productService) {
    this.productService = productService;
}

// GET /products - returns view name "products/list"
@GetMapping
public String listProducts(Model model) {
    model.addAttribute("products", productService.getAll());
    return "products/list"; // ViewResolver - templates/products/list.html
}

// GET /products/42 - path variable extraction
@GetMapping("/{id}")
public String getProduct(@PathVariable Long id, Model model) {
    model.addAttribute("product", productService.findById(id));
    return "products/detail";
}

// POST /products - form submission
@PostMapping
public String createProduct(@ModelAttribute ProductForm form) {
    productService.create(form);
    return "redirect:/products"; // PRG pattern - redirect after POST
}
}

5. REST Controllers vs Traditional MVC Controllers

Spring supports two controller styles: @Controller for traditional MVC (returns view names for rendering HTML) and @RestController for REST APIs (returns data serialised to JSON/XML directly). The difference is one annotation - but the underlying behaviour is meaningfully different.

@RestController is shorthand for @Controller + @ResponseBody. The @ResponseBody annotation tells Spring to skip the ViewResolver entirely and write the return value directly to the HTTP response body as JSON (using Jackson, which Spring Boot auto-configures).

The List<UserDto> return type from getAllUsers() - serialised directly to a JSON array - uses Java generics throughout. Board Infinity's generics in Java guide covers the <UserDto> type parameter: it tells Spring's Jackson serialiser exactly what type each element in the JSON array represents, giving compile-time type safety from the service layer through the controller to the HTTP response. The ResponseEntity<UserDto> return type in getUserById() and createUser() - and its generic <T> parameter - uses the same generics model: ResponseEntity<T> wraps any response body type with HTTP status and headers control, and the type parameter <UserDto> ensures compile-time checking that the response body type matches what the client expects. The understanding wrapper class in Java guide is also relevant: @PathVariable Long id uses the Long wrapper rather than long primitive - Spring's type conversion system needs nullable wrapper types to handle missing path variables correctly.

// @Controller - returns view name, renders HTML
@Controller
public class PageController {
@GetMapping("/dashboard")
public String dashboard(Model model) {
    model.addAttribute("user", "Alice");
    return "dashboard"; // templates/dashboard.html (Thymeleaf)
}
}
// @RestController - returns JSON directly
@RestController           // = @Controller + @ResponseBody on every method
@RequestMapping("/api/users")
public class UserApiController {
private final UserService userService;

public UserApiController(UserService userService) {
    this.userService = userService;
}

@GetMapping
public List<UserDto> getAllUsers() {
    return userService.findAll(); // serialised to JSON - no view
}

@GetMapping("/{id}")
public ResponseEntity<UserDto> getUserById(@PathVariable Long id) {
    return ResponseEntity.ok(userService.findById(id));
}

@PostMapping
public ResponseEntity<UserDto> createUser(@RequestBody CreateUserRequest req) {
    UserDto created = userService.create(req);
    return ResponseEntity.status(201).body(created);
}

@DeleteMapping("/{id}")
public ResponseEntity<Void> deleteUser(@PathVariable Long id) {
    userService.delete(id);
    return ResponseEntity.noContent().build(); // 204 No Content
}
}

6. Validation in Spring: Bean Validation + Custom Validators

Spring Boot integrates with the Bean Validation API (JSR-380) out of the box via the spring-boot-starter-validation dependency. This lets you annotate your request DTOs with constraints like @NotNull, @NotBlank, @Size, @Email, and @Min - and Spring validates them automatically before your controller method runs.

The validation annotations on CreateUserRequest - @NotBlank, @Size, @Email, @Min - are applied to private fields. The encapsulation that makes these fields private is also what makes the validation contract meaningful. Board Infinity's abstraction vs encapsulation in Java guide explains why private fields with validation annotations form a clean data contract: the CreateUserRequest class encapsulates its validation rules together with the data they protect - external code can't bypass @NotBlank on name by directly setting the field. When validation fails, Spring throws MethodArgumentNotValidException - an unchecked exception that propagates up to the @RestControllerAdvice handler. Board Infinity's throw and throws in Java guide covers the Java exception model that makes this propagation work: MethodArgumentNotValidException extends RuntimeException (unchecked), so it bubbles up through the call stack without requiring try-catch at every level until the global handler catches it.

// Request DTO with validation constraints
public class CreateUserRequest {
@NotBlank(message = "Name is required")
@Size(min = 2, max = 50, message = "Name must be 2-50 characters")
private String name;

@NotBlank(message = "Email is required")
@Email(message = "Must be a valid email address")
private String email;

@NotBlank(message = "Password is required")
@Size(min = 8, message = "Password must be at least 8 characters")
private String password;

@Min(value = 18, message = "Must be at least 18 years old")
private int age;
}
// Controller activates validation with @Valid
@RestController
@RequestMapping("/api/users")
public class UserController {
@PostMapping
public ResponseEntity<UserDto> create(
        @Valid @RequestBody CreateUserRequest request) {
    // @Valid triggers Bean Validation before this method body runs
    // If any constraint fails - MethodArgumentNotValidException thrown
    return ResponseEntity.status(201).body(userService.create(request));
}
}