Best practices with Ruby on Rails

Ruby gem

Today we will talk about a well known good practice when working with MVC frameworks. Who never heard about the ‘fat model, skinny controller’ phrase?
That is a really widespread idea. However, there are a lot of approaches that can help you to skinny both our model, views, and controllers. This can help you to test better and keep your code reusable.
In this post, we will talk about the separation of the logic in methods and classes and how not to keep all of your code just in Model, View or Controllers.
First of all, let’s remember about the MVC architecture pattern and what is the each one responsibility. Basically, MVC stands for Model, View, Controller and its main goal is to separate the logic into three main layers.

Model: responsible for representing data, data validation, business logic and all the things related with data.

View: it shows information to the user.

Controller: it is the intermediary layer between model and view. It receives the user request, through the router, and then ask the model for data and shows the response in the view.

An important thing to highlight here is that not everything should be kept in those three places. Some other classes are really useful when you intend to DRY up your app. Let’s start talking about it.

Helpers

Rails allow you to use helpers so you can extract logic from your view. When you need to format, or to verify something before display it, you should use it. For example, instead of doing this:

<% if @product && @product.price.present? %>
 <%= @product.price %>
<% end %>

You should do this:

module ProductHelper
  def product_price(product)
    product.price if product && product.price.present?
  end
end

Then in your view, you just have to call your pre-defined method. Like this:

<%= product_price(product) %>

This way, you can test your helper easily and also reuse it many times instead of bringing logic to the view. Usually, it is automatically available to be used in your view and in your controller. However, it is more common to use it for views (there are other auxiliaries for back end DRY up). All the helpers you declare in a module will be available in all your views — not just in the same named view.

Services

Service is a way to DRY up your controller. People usually create a directory ‘/service’ and put files inside it. Each file is one class with one initializer, input and specific/related methods for that class.
Why use it? if you want to concentrate the core logic of your app and also want skinny models and controllers, you should go for it.

One example of service use case:

Class ProductLogisticService
  def initialize(params)
    //initialize your variables
  end
  def addInStock
    //method to add a product in your stock
  end
  def removeFromStock
   //method to remove a product from your stock
  end
end

Now, when you need to call it you should just have to type:

ProductLogisticService.new({params}).addInStock

Easy, right? So, there are a lot of alternatives to use instead just transfer the logic from your model. And that is the point here!
Two major rails guiding principles:
- Don’t Repeat Yourself
- Convention Over Configuration

So, remember: let nothing fat.