MVC and Routing in Rails
Fast recall
Quick revision
Core answer
Whether you can name M/V/C's jobs (model: data+logic; view: presentation; controller: orchestration) and how routing maps URLs to actions.
Putting presentation in the model (model knows HTML) or business logic in the view — break the separation.
MVC: Model (data+logic), View (presentation), Controller (orchestration). Routing maps URL+verb to controller#action. Rails' convention wires them automatically.
Interview-ready guide
Interview answer
Rails applies Model-View-Controller to separate the parts of request handling. The model represents data and domain behaviour, the view produces a representation such as HTML or JSON, and the controller connects an incoming request to the required work.
Routing sits before the controller. Rails compares the request's HTTP verb and path with config/routes.rb, selects a target such as ProductsController#show, and extracts path values like :id into params. A route identifies the action; it should not implement the action's business rules.
For example, GET /products/42 can match products#show. The controller loads Product.find(params[:id]), then Rails renders the show template or a JSON representation. The model knows how a Product is stored and validated, while the view decides how that product is presented.
Controllers should remain request-oriented: authentication, permitted input, calling domain operations, and choosing a response. Large calculations and reusable business rules belong in models or dedicated objects; SQL and HTML mixed directly into the action make the boundaries difficult to test.
The complete path is request, route, controller, domain work, representation, and response. MVC is valuable because changing the HTML usually does not change the model rule, and changing persistence should not require rewriting URL dispatch. It also gives route, request, model, and view tests a natural responsibility to verify directly.
MVC and Routing in Rails
Direct Answer
Rails uses MVC to divide a web request into responsibilities: the router selects a controller action from the HTTP verb and URL; the controller coordinates the use case; models handle data and domain rules; and a view or serializer builds the response representation. Routing is the entry map into MVC—it does not contain the business operation itself. This separation keeps request handling, domain behaviour, and presentation independently understandable and testable.
Deep Dive & Architecture
Before MVC code runs, the Rack server and Rails middleware build an HTTP request environment. The router then considers routes in declaration order. A match supplies a controller name, action name, and any dynamic segments. If no route matches, the request never reaches an application controller action.
The controller is the HTTP boundary. It can read headers, session data, query or body parameters, and the values captured by the route. It asks models or service objects to perform work and prepares only the state the representation needs. An instance variable such as @product is one common bridge to an HTML view.
A model does not mean 'every line that is not a controller'. Active Record models map records and can protect data invariants, while a separate domain or service object may coordinate operations across several records or external systems. The useful boundary is that these objects should not depend on whether the caller eventually renders HTML or JSON.
Rendering creates the response body; Rails also selects a status and headers. The same controller action can negotiate different formats, but each format still represents the same result. This journey gives failures a location: routing mismatch, request validation, domain rule, persistence, or presentation.
Code Example
# config/routes.rb
Rails.application.routes.draw do
resources :products, only: [:show]
end
# app/controllers/products_controller.rb
class ProductsController < ApplicationController
def show
@product = Product.find(params[:id])
end
end
# app/views/products/show.html.erb
# <h1><%= @product.name %></h1>
Common Mistakes & Pitfalls
Putting presentation in the model (model knows HTML) or business logic in the view — break the separation.
Check your understanding
Answer these without looking back at the article.
- What happens before a controller action runs?
- Which responsibilities make a Rails controller too large?
- How can the same action return HTML and JSON representations?
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.