Ruby on Rails 4 and Symfony 2 as MVC Frameworks

Author: Ievgen Cherkashyn

In this post we'll get more technical by discussing the MVC stack for these frameworks.

MVC stands for Model - View - Controller, and represents one of the ways that an application's logic can be split into a few interconnected parts to make development easier. According to the MVC architecture, a user interacts with an application via the Controller. Than Controller passes the user's manipulations to the Model, which then updates the View of the application that the user sees and can interact with.

Let's learn how the MVC stack works with the Ruby on Rails and Symfony frameworks.

Routes

Routes allow developers to introduce easy-to-read and easy-to-use URLs mapping areas of an application.

Both Ruby on Rails and Symfony routes allow:

  • declaring dynamic routes with parameters such as /product/name
  • controlling route parameters and HTTP methods via requirements
  • visualizing the tables of all registered routes in the application
  • generating URLs based on a known route's name and parameter set
  • generating CRUD routes for resources

    • What's different between Rails and Symfony is that Symfony 2 can also import existing routes from YML, XML and PHP files, while Ruby on Rails instead can define concerns for frequently used routes for their further reuse.

    Controllers

    In frameworks, controllers are callables that developers create to take information from HTTP requests and return HTTP responses. A response can have any representation: it may be an HTML page, a serialized JSON array, an XML document or a 404 error. Controllers contain any logic you want your application to have in order to render the content of a page.

    To put it simply, a controller is a link between data and its view.

    For instance, let's assume that a user has edited their profile and clicked Save. When they click, an update request is sent to a server. This is where a controller will receive data about profile changes and pass this data to the business logic layer, where it will then be checked for validity (correct format for email, correct username, etc.) If the data is not valid, the controller will be notified and will return an error message to the user via the view.

    By default, Ruby on Rails follows the RESTful approach. It uses HTTP verbs (GET, PUT, POST and others) and well-organized URLs to represent required resources. And its tool allows handling basic CRUD actions (Create, Read, Update, Delete) on data.

    Typical actions in Ruby on Rails are the following:

  • index — An action that returns a list of all resources; for example, GET /users will hit the index action on the Users Controller, listing known users.
  • show — An action that performs a read operation for a single resource; for example, GET /users/1 will hit the show on the Users Controller, showing the details of the User with id 1.
  • new — The action to show a new object form - in our case, the new User form; for example, GET /users/new will hit the new action on the Users Controller and show the new user form.
  • create — A post action to take the form data from the new action and attempt to create a record; for example, POST /users will hit the create action on the Users Controller, typically with some associated form data.
  • edit — Will show the form to edit a specific resource; for example, GET /users/1/edit will hit the edit action on the Users Controller and show a form to edit the User with id 1.
  • update — Will attempt to update the given resource; for example, PUT /users/1 will hit the update action on the Users Controller and attempt to update the User with id 1.
  • destroy — Will attempt to destroy a given resource; for example, DELETE /users/1 will hit the destroy action on the Users Controller and attempt to destroy the User with id 1.

    • Symfony 2 also has controllers that provide similar responsibilities:

  • Get requests, receive URLs, headers, request bodies and route parameters
  • Provide the call to the business logic layer
  • Prepare and provide the response object at the end of the execution
  • Render Twig templates
  • Perform redirects
  • Validate a CSRF token

    • A CRUD generator is also present in Symfony 2. It generates controllers for given entities and lets you perform the following actions with them:

  • List all records
  • Show one given record identified by its primary key
  • Create a new record
  • Edit an existing record
  • Delete an existing record

    • Ruby on Rails 4 and Symfony 2 are similar in terms of creating and managing controllers, and in practice we don't encounter any notable differences when using them.

    Models (Interacting With Databases)

    Most frameworks use two programming techniques to interact with databases:

  • DBAL (Database Abstraction Layer). A DBAL provides an API to help developers interact with the database of their choice without diving into the specifics of a particular database (every database has its own unique interface).
  • ORM (Object-Relational Mapping). Represented by a library, ORM encapsulates the code required to manipulate data and creates a "virtual object database" to help you interact with objects directly in your own programming language (so you don't need to use SQL directly).

    • Ruby on Rails uses Active Record as its default ORM. Active Record serves as the Model in the MVC architecture and is responsible for representing business data and logic. It helps create and use business objects whose data requires persistent storage to a database. When using Active Record, you can think of database rows as standard objects and manipulate them accordingly, which is an intuitive way of interacting with a database.

    Symfony 2 is integrated with Doctrine. Although it's also an ORM library, Doctrine follows the Data Mapper pattern. According to this pattern, Doctrine represents a data access layer that lets you perform CRUD actions with objects.

    As a result, Doctrine also aims to simplify interaction with databases, but requires you to map your database tables to particular PHP classes, and the columns of those tables to particular properties of those classes.

    In practice, both Active Record and Data Mapper patterns have pros and cons:

    Developers of ORM libraries usually choose either Data Mapper or Active Record for you.

    Templates

    When a controller needs to generate some content - either HTML, XML or any other type - it hands the work to a templating engine, which is represented as a text file able to generate any text-based format, from LaTex to HTML.

    Symfony 2 comes with Twig, a powerful templating language that allows you to write readable, concise, and designer-friendly templates.

    Twig provides three types of syntax:

  • {{ … }}

    • "Says something." prints a variable or the result of an expression to the template.

  • {%... %}

    • "Does something." a tag that controls the logic of the template; it is used to execute statements such as for-loops.

  • {#... #}

    • "Comment something." the equivalent of the PHP / comment / syntax. It's used to add single or multi-line comments. The content of the comments isn't included in the rendered pages.

    Twig supports both user-defined functions and features coming with standard libraries. It also contains tags and filters that modify content before rendering it.

    Common elements in templates (such as headers and sidebars) are called blocks. They work like PHP classes and allow inheritance.

    With Ruby on Rails, we're talking about Embedded Ruby or ERB, which is the default templating language in Rails.

    There are three main markup elements in Embedded Ruby:

    • Wrap Ruby code whose return value will be output in place of the marker
    • Wrap Ruby code whose return value will NOT be output
    • Wrap Ruby code whose return value will NOT be output (and no blank lines will be generated)

    HTML and text use no markers and appear plainly on the page.

    However, a lot of developers prefer to switch to HAML templates. HAML is an alternate template language that currently dominates in the Ruby on Rails world. HAML is so popular because:

  • It's easy to read and expresses the DOM hierarchy visually
  • It's very well-maintained by a huge community
  • It's easy to learn
  • It borrows the CSS syntax, so it's popular among designers as well
  • It's almost as fast as plain ERB
  • It's already been ported to other languages
  • It helps you avoid making many regular types of errors

    • In the end, Twig, ERB, and HAML are all great template engines that offer everything you need to write templates. In the case of Ruby on Rails, ERB looks pretty much like HTML, so it's a great choice for HTML/CSS developers, but HAML is often preferred for its concise code.

    Both frameworks stick to the MVC architecture, and provide great tools for managing the common tasks of interacting with databases, routing URLs and automatically generating content.

    Originally published https://rubygarage.org/blog/ruby-on-rails-and-symfony-as-mvc