Rails Project Structure & MVC

Reviewed & published by Brayan K

Ruby on Rails is a full-stack web framework built on Ruby, and it organizes every app around the MVC pattern — Model, View, Controller — so your code has a clear, predictable home.

Part of the free Ruby course at LearnCodingFast — hands-on lessons with worked examples and the output they print, plus practice exercises and a quick quiz.

By the end of this lesson you'll create a new app with rails new, recognize the key folders, understand how a request flows through MVC, and start the server.

What You'll Learn in This Lesson

• Creating an app with rails new
• The app/, config/, and db/ folders
• The Model, View, Controller roles
• How a request flows through MVC
• Convention over configuration
• Starting the dev server with rails server

1️⃣ Creating an App and Starting the Server

Use rails new appname to scaffold a complete application, then rails server to run it. By default it listens on http://localhost:3000.

# Create a new Rails app and move into it.
rails new blog
cd blog

# Boot the development server.
rails server     # short form: rails s

# Then open http://localhost:3000 in your browser.
# You'll see the Rails welcome page — your app is alive.

Here are the most important folders Rails generates for you.

# The key folders rails new generates (simplified):
blog/
  app/                 # YOUR application code lives here
    controllers/       # Controllers: handle requests
    models/            # Models: data + business logic
    views/             # Views: HTML templates (ERB)
    helpers/           # View helper methods
    assets/            # CSS, JS, images
  config/
    routes.rb          # Maps URLs to controller actions
    database.yml       # Database connection settings
  db/
    migrate/           # Database migrations
    schema.rb          # Current database structure
  Gemfile              # Gems (libraries) the app depends on

2️⃣ How MVC Fits Together

A request travels through four pieces: the router picks a controller action, the controller asks a model for data, and a view turns that data into HTML. Each part has a single, focused job.

# MVC = Model, View, Controller. Each has ONE job.

# 1) ROUTER (config/routes.rb) maps the URL to a controller action.
get "/posts", to: "posts#index"

# 2) CONTROLLER (app/controllers/posts_controller.rb)
class PostsController < ApplicationController
  def index
    @posts = Post.all      # ask the MODEL for data
  end                      # then Rails renders the matching VIEW
end

# 3) MODEL (app/models/post.rb) talks to the database.
class Post < ApplicationRecord
end

# 4) VIEW (app/views/posts/index.html.erb) builds the HTML.
# <% @posts.each do |post| %>  ...  <% end %>

Your turn. Match each file to its MVC role — Model, View, or Controller.

# 🎯 YOUR TURN — match each piece to its MVC role.
# Fill in the blank with: Model, View, or Controller.

# app/models/article.rb           -> ______   (talks to the database)
# app/controllers/...controller.rb -> ______   (handles the request)
# app/views/articles/show.html.erb -> ______   (builds the HTML)

# ✅ Expected answers:
#    Model
#    Controller
#    View

Mini-Challenge: Trace a Request

Walk through what happens when a user visits /posts, naming each step in order.

# 🎯 MINI-CHALLENGE: describe the request lifecycle.
#
# A user visits http://localhost:3000/posts. In order, name:
# 1. The file that decides which controller handles the URL.
# 2. The controller action that runs.
# 3. Where the data comes from.
# 4. What gets sent back to the browser.
#
# ✅ Example answer:
#    config/routes.rb
#    PostsController#index
#    the Post model (database)
#    the index view (HTML)

# your answer here

Common Errors (and the fix)

• Running rails commands outside the app — Most commands must run from inside the project folder; cd blog first.
• Port 3000 already in use — Stop the other server, or run rails server -p 4000 to pick a different port.
• Putting code in the wrong folder — Models go in app/models, controllers in app/controllers, views in app/views.
• Fighting the conventions — Naming a controller oddly breaks Rails' auto-wiring; follow the plural/singular conventions.
• Editing schema.rb by hand — Don't; change the database through migrations instead.

Pro Tips

• 💡 Learn the folders: knowing where things live makes navigating any Rails app fast.
• 💡 Use rails console: rails c lets you experiment with your models interactively.
• 💡 Embrace conventions: the less you fight Rails, the less code you write.

📋 Quick Reference — Rails Basics

🎉 Lesson Complete!

• ✅ rails new scaffolds a complete application
• ✅ app/ holds models, views, and controllers
• ✅ MVC separates data, presentation, and coordination
• ✅ A request flows router → controller → model → view
• ✅ Convention over configuration means less boilerplate

Practice quiz

Continue this course

• Previous: Intro to Rails
• Next: Routing & RESTful Resources — config/routes.rb, resources, the seven RESTful routes and route helpers
• Quick reference: Ruby cheat sheet

Frequently asked questions

What exactly does rails new create?

Running rails new blog generates a complete, ready-to-run application: the app/ folder for your code (models, views, controllers), config/ for settings like routes and the database, db/ for migrations and schema, a Gemfile listing dependencies, and much more. It even installs the gems and sets up a default SQLite database. From that single command you get a working skeleton you can boot immediately with rails server — Rails does the tedious setup so you can start building features right away.

What is the MVC pattern?

MVC stands for Model, View, Controller — three layers, each with one clear job. The Model holds data and business logic and usually maps to a database table (via ActiveRecord). The View is the template that produces what the user sees, normally HTML built with ERB. The Controller sits in the middle: it receives a request, asks models for data, and picks a view or redirect to respond with. Separating these concerns keeps code organized: data logic stays in models, presentation stays in views, and coordination stays in controllers.

What does 'convention over configuration' mean?

It's the Rails philosophy that you should follow sensible naming and structure conventions rather than configuring everything by hand. For example, a Post model automatically maps to a posts table, a PostsController is expected in app/controllers, and its views live in app/views/posts. Because Rails knows where things go, you write far less boilerplate. Following the conventions makes your app predictable to other Rails developers and unlocks a lot of automatic wiring; you only reach for configuration when you genuinely need to deviate.

How do I run the app while developing?

Use rails server (or the short rails s) from inside your project directory. That boots a local web server — by default Puma on port 3000 — so you can open http://localhost:3000 in a browser and see your app. The server reloads your code on each request in development, so most changes appear when you refresh the page. Press Ctrl-C to stop it. There's also rails console (rails c) for an interactive Ruby session with your app loaded, which is handy for poking at models and data.