Sep 30, 2015
Table of contents:
Ruby on Rails is built upon many of the most well known and used software design patterns in the industry. Two of those patterns are the Active Record pattern, and Model-View-Controller.
Part of the beauty and simplicity of Rails as a framework is that these patterns have been accepted as “The Rails Way”.
By following “The Rail Way” you will make your experience of working with Ruby on Rails much more enjoyable because all of the building blocks will fall into place.
In today’s tutorial we are going to be looking at creating our first Ruby on Rails Model.
Model-View-Controller (MVC) is a software design pattern that separates the concerns of a piece of software into three distinct areas.
The View is what the user sees their screen and includes any presentation and interactivity.
The Model is where the “business logic” of the application resides. This is the heart of your application and typically includes the code that makes your application unique.
The Controllers are the traffic conductors that transport messages between the Model and the View. The Controller deals with requests from the View and then returns responses from the Model.
MVC is a very well established design pattern in the world of software development. If you would like to read more on the topic, take a look at What is MVC? (Model-View-Controller).
Ruby on Rails is very much built upon the Model-View-Controller design pattern.
In a Rails application, your Model will be responsible for holding the business logic of your application as well as validation and talking with the database.
Ruby on Rails also fully embraces the Active Record pattern. I’ve written previously about What’s the difference between Active Record and Data Mapper?, but if the term Active Record is new to you, don’t worry about it.
So for example, if you were building a blog application, you might have an Article
Model that represents the articles of your blog.
The Article
Model would be responsible for making sure all articles had a title
and a body
.
When you wanted to create a new article, you would create a new instance of your Article
Model and add the title
and body
. The Model would then take care of storing itself into the database.
And when you wanted to retrieve an article from the database, you would use the Article
Model to find the specific article you were looking for.
If you are new to the world of programming this is probably a lot to take in right now. Don’t worry about it though, just keep going as I’m sure it will all fall into place.
Last week, when we created the new Rails Project, we ran rails new project_name
to automatically generate all of the files that we will need.
Rails has a number of these generators that can deal with creating files for you. This will save you a lot of time and headaches.
In order to interact with Rails through the command line we need to use bin/rails
. If you run that command from within your project you will be presented with a page of commonly used commands.
We need to create a new Model and so we can run the following generator command:
bin/rails g model Article title:string body:text
Here I’m using the g
short-cut alias of the generate
command.
We next pass model
because we want to use the model generator.
Next we pass the name of the model to create, in this case Article
.
And finally we pass the attributes of the model. In this case I’m using title:string body:text
. The title
and body
are the names of the attributes of the model and the string
and text
are the types of those attributes.
When you run that command you should be presented with the following output:
invoke active_record
create db/migrate/20150222140120_create_articles.rb
create app/models/article.rb
invoke test_unit
create test/models/article_test.rb
create test/fixtures/articles.yml
This output is telling us the following files were created:
We will need each of these files when creating the application and so Rails automatically generates them with the correct filename and location according to the Rails convention.
The first file that we will look at that we haven’t mentioned so far is the migration file.
The migration file tells the database what tables should be created.
This allows you to “version control” your database because your Rails project will be able to instruct the database on how it should be built.
This is beneficial for a number of reasons.
Firstly it makes deploying easier. When you need to make a change to an existing database you can set the migration to automatically make the change as part of the deployment process. This saves you from having to make a change to a live database manually.
Secondly it makes working with others easier. When you pull in code changes from your colleague you don’t need to ask how the database schema needs to be changed because you can simply run the database migration.
With the migration in place we can run the following command to create the database table:
bin/rake db:migrate
Models in Rails are very powerful. They have a lot of responsibility, and so there is a lot to cover.
Instead of cramming everything into one article I’m going to take a deeper dive in individual articles.
In today’s article we looked at the purpose of models and how they fit into MVC. We looked at the responsibility of the model object. We also saw how we can use the rails generators to create a new model. And we saw how a migration file can automatically create the database table for you.
If you are new to web application development, this might be a lot to take in. However, Rails provides a lot of these helpers and conventions to take away a lot of the stress and overhead of build turning your idea into a working product. Once you get the hang of the new terminology, you will probably find everything just falls into place.