MVC Pattern Explained — Model, View, Controller
Fast recall
Quick revision
Core answer
Understanding of fundamental architectural pattern separation and its purpose in web applications
Thinking MVC is Spring-specific or just naming the three layers without explaining why separation matters
Explain how Spring MVC implements this pattern with DispatcherServlet as front controller and show real request flow
Interview-ready guide
Interview answer
MVC is a design pattern that splits your application into three parts: Model, View, and Controller.
It's been around since the seventies and isn't specific to Spring. The Controller handles incoming HTTP requests — it's like a waiter taking orders. The Model contains your business logic and data — that's the kitchen preparing food.
The View is what gets sent back to the client — the plated dish. In a Spring Boot REST API, the Controller is your @RestController class that maps URLs. The Model is your service layer with business rules and your domain objects like Order or Customer.
The View is usually JSON that Jackson creates from your response objects. The whole point is separation of concerns. You don't put database queries in your controller.
You don't write business logic in your view. Each layer does one thing well. If you need to change how orders are validated, you only touch the service class.
If you need to add a new endpoint, you only touch the controller. This makes the code easier to test because you can test business logic without spinning up a web server. Spring implements this with DispatcherServlet as the front controller that routes requests to your methods.
A common mistake is putting everything in the controller — that's called a fat controller and it breaks the pattern. Keep controllers thin, they should just coordinate between the request and your service layer.
MVC Pattern Explained — Model, View, Controller
Direct Answer
MVC (Model-View-Controller) is an architectural pattern that separates an application into three components: Model (data and business logic), View (presentation/UI), and Controller (handles HTTP requests, coordinates model and view). It promotes separation of concerns.
Code Example
@RestController
@RequestMapping("/api/orders")
public class OrderController { // Controller layer
private final OrderService orderService;
public OrderController(OrderService orderService) {
this.orderService = orderService;
}
@GetMapping("/{id}")
public ResponseEntity<OrderResponse> getOrder(@PathVariable Long id) {
var order = orderService.findById(id); // Delegates to service
return ResponseEntity.ok(new OrderResponse(order));
}
}
@Service
public class OrderService { // Model layer - business logic
private final OrderRepository repository;
public Order findById(Long id) {
return repository.findById(id)
.orElseThrow(() -> new OrderNotFoundException(id));
}
}
record OrderResponse(Long id, String item, BigDecimal price) { // View layer representation
OrderResponse(Order order) {
this(order.getId(), order.getItem(), order.getPrice());
}
}
Common Mistakes & Pitfalls
- Fat Controllers: Learners put business logic directly in controller methods — calculating totals, validating rules, querying databases. Controllers should only handle HTTP concerns (parsing request, returning response) and delegate to services.
- Skipping Service Layer: Calling repository methods directly from controllers because it's fewer lines of code. This scatters business logic across controllers and makes testing harder.
- Mixing View Logic: Building JSON strings manually or formatting data in controllers instead of using dedicated response DTOs. Let Jackson handle serialization and keep controllers thin.
Check your understanding
Answer these without looking back at the article.
- What is the difference between @Controller and @RestController?
- What is DispatcherServlet and what role does it play?
- What is a Front Controller design pattern?
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.