Principles of MVC for Rails Developers

Principles of MVC For rails Developers
View Ruby On Rails Course at: www.edureka.co/ruby-on-rails
For more details please contact us:
US : 1800 275 9730 (toll free)
INDIA : +91 88808 62004
Email Us : webinars@edureka.co
For Queries:
Post on Twitter @edurekaIN: #askEdureka
Post on Facebook /edurekaIN

www.edureka.co/ruby-on-rails
Objectives
At the end of this module, you will be able to understand:
 Challenges Faced when Designing an Application Without Framework
 MCV Design Patterns
 Logic Behind MVC
 DRY and Convention Over Configuration
 MVC Benefits
 Demo on MVC in RAILS

Challenges Faced when Designing an Application without a Framework
 Complexity in direct coding  Everything must be tested, which is difficult
 Difficult to re-use code
 Hard code everything from
scratch
 Teamwork challenges -
parallel programming cannot
be done efficiently

 Leads to disorganization  Change one thing, break another
Challenges Faced when Designing an Application without a Framework

The Solution is to use Design Patterns
Design Patterns is the way to organize a program
in a proper manner
One such design pattern is MVC

Introduction – What is MVC
MVC Introduction
MVC is acronym for Model-View-Controller
A software design pattern for developing web and desktop applications
In simple words, a better way of separating the logic of your application from
the display.

 Originally described in terms of a design pattern for use with Smalltalk by Trygve Reenskaug in 1979.
 His paper was published under the title "Applications Programming in Smalltalk-80: How to use Model-View-
Controller", and paved the groundwork for most future MVC implementations.
 MVC design pattern is used to separate an application’s data, business logic, and presentation; doing so facilitates
the creation of more maintainable, reusable, and testable code.
• Model - Data Layer
• View - User Interface Layer
• Controller - Interacts with the Model
MVC Introduction

MVC - Illustration
Web
Browser/Client
HTTP Request
HTTP Response
CONTROLLER MODEL
VIEW
Data object
Request
Data Objects
Response
Render dataEvents
(GET/POST)
Handled by Framework
(Hidden from user)
Database
Database
Request
Raw Data
Response
MVC Container
Website User
http://www.mywebsite.com

Model
Data access routines and some business logic can be defined in the model.
Model is responsible for providing the data from the database and saving the data
into the data store.
Models are active representations of database tables: they can connect to your
database, query it (if instructed to do so by a controller) and save data to the
database.
No interaction between models and views: all the logic is handled by controllers.
MVC - Data Layer

View
Views define exactly what is presented to the user.
It collects data from the user and gives it to controller and controller invokes the
required model.
Controllers pass data to each view to render in some format.
Views can be described as template files that present their content to the user:
variables, arrays and objects that are used in views are registered through a
controller.
Views should not contain complex business logic; only the elementary control
structures necessary to perform particular operations, such as the iteration of
collected data through a foreach construct, should be contained within a view.
MVC - User Interface Layer

Controller
Controllers bind the whole pattern together.
Controller is intermediary between View and Model.
Controllers contain the logic of your application.
Each controller can offer different functionality; controllers retrieve and modify data by
accessing database tables through models; and they register variables and objects, which
can be used in views.
Once request is received from client it executes the appropriate business logic from the
model, decide which view to display based on the user's request and other factors, pass
along the data that each view will need, or hand off control to another controller entirely.
MVC - Interacting With Model

DRY
 DRY just means "Don't Repeat Yourself". Make sure that when you write code, you only write it one time.
 The DRY principle is stated as "Every piece of knowledge must have a single, unambiguous, authoritative
representation within a system."
Reference: https://maurits.wordpress.com

Convention Over Configuration
 Convention over configuration (also known as coding by convention) is a software design paradigm which seeks
to :
 For example, if there is a class Sale in the model, the corresponding table in the database is called "sales" by default.
It is only if one deviates from this convention, such as calling the table "product sales", that one needs to write code
regarding these names.
Not losing
flexibility
Decrease
number of
decisions on
developers
Gain
Simplicity

MVC Benefits

 Rails application can be created using the following command
>rails new app_name
 When you create an application using the rails helper script, you can see that a new directly structure is
created for your application. The directory structure will have to following directories that will be explained in
the next slide.
Creating a Rails Application

Directory Layout
File /Folder Purpose
app/
Contains the controllers, models, views, helpers, mailers and assets for your
application.
bin/
Contains the rails script that starts your app and can contain other scripts you use to
deploy or run your application.
config/ Configure your application's routes, database, and more
condig.ru Rack configuration for Rack based servers used to start the application.
db/ Contains your current database schema, as well as the database migrations
Gemfile
Gemfile.lock
These files allow you to specify what gem dependencies are needed for your Rails
application. These files are used by the Bundler gem.
Lib/ Extended modules for you application
Log/ Application log files

Directory Layout (Contd.)
File /Folder Purpose
public/ The only folder seen by the world as-is. Contains static files and compiled assets.
Rakefile
This file locates and loads tasks that can be run from the command line. Rather than
changing Rakefile, you should add your own tasks by adding files to the lib/tasks
directory of your application
README.rdoc
This is a brief instruction manual for your application. You should edit this file to tell
others what your application does, how to set it up, and so on.
test/ Unit tests, fixtures, and other test apparatus.
tmp/ Temporary files (like cache, pid, and session files).
Vendor/
A place for all third-party code. In a typical Rails application this includes vendor’s
gems.

 Rails application can be booted using the
following command
>rails server
 This command will fire up WEBrick, a web
server distributed with Ruby.
» Default environment is development
» Default port is 3000
» http://127.0.0.1:3000
Running Rails Application

To see your application in action, open a browser window and navigate to http://localhost:3000
Running Rails Application (Contd.)

Demo on
MVC in Rails

Questions
Slide 21 www.edureka.co/ruby-on-railsTwitter @edurekaIN, Facebook /edurekaIN, use #AskEdureka for Questions

Principles of MVC for Rails Developers

Principles of MVC for Rails Developers

More Related Content

What's hot (20)

Similar to Principles of MVC for Rails Developers (20)

More from Edureka! (20)

Recently uploaded (20)

Principles of MVC for Rails Developers