The Model-View-Controller Paradigm

The Birth of MVC

• Designed by Trygve Reenskaug in 1979
• Smalltalk-76
• Intended for Graphical User Interfaces

MVC as We Know It

Kalid Azad

MVC as It Was Designed c. ~1980

Amir Salhefendic

• Provide graphical interfaces for textual/CLI systems
• Modular in such a way that each GUI system was independent
• Each UI system could re-use the core application without modification

MVC as It Was Designed c. ~1980, 2

Amir Salhefendic

• The model, view, and controller are independent triads
• The view manages the graphical/textual output
• The model manages the behavior and data, responds to queries about state and to modify state

Object-Oriented Programming

SOLID

• Single Responsibility
• Open-Closed
• Liskov Substitution
• Interface Segregation
• Dependency Inversion

The minor three are important, but not useful enough for this talk

SRP and DI: peas and carrots!

Single Responsibility

Single Responsibility, Cont.

• You will create more classes than you might expect
• Your classes will likely be small, <5 methods is common
• Easily unit-tested

Dependency Inversion

Dependency Inversion, Cont.

Think less about what an object does, and more about what it can do

Hard-Coded Dependency

class Greeter
{
    public function sayHello()
    {
        echo CurrentUser::sayHello();
    }
}

Dependency Inversion

class Greeter
{
    public function __construct($hello_sayer)
    {
        $this->hello_sayer = $hello_sayer;
    }

    public function sayHello()
    {
        echo $this->hello_sayer->sayHello();
    }
}

Now our class can be used in other contexts

SOLID is About Ease of Change

• Transparent
• Reasonable
• Usable
• Exemplary

Practical Object-Oriented Design in Ruby, Sandi Metz

Automated Testing

Testing is paramount to any projects long-term success

Discuss history with tests

The vast-majority of your tests should be automated

Using humans to run through a suite of changes is dumb and a waste of time

Bob Martin: Using humans where machines are better off is immoral

You should be confident that any change you make does not have unintended consequences

Making one change here, and the whole application breaks

Removing tests is perfectly valid...

If you remove the functionality they represent

Discuss refactoring tests, cleanup

Domain-Driven Design (DDD)

What is DDD?

• Patterns and principles to map real-world business ideas to code
• A deeper application of SOLID principles
• Application-level abstraction

How does this Relate to MVC?

• Your business logic is your domain layer
• Your MVC is your application layer that asks your domain layer to make decisions
• Your MVC framework is a detail that can be deferred

Why not just use fat models/skinny controllers?

Single Responsibility Principle

Models are part of your persistence layer.

So skinny controllers?

Put your controllers on a very restrictive diet

Heresy, According to Some

A project should NOT start with any of the following:

~$ rails new my-project
~$ composer create-project laravel/laravel my-project
~$ django-admin.py startproject my-project

What makes your application special is its domain

If it's not special, buy a product and move on with your life