MVC Architecture in Rails

                  MVC (Model-View-Controller) is the architecture that provides flexibility and scalability of the applications, Ease of keeping code DRY, making it clear where different types of code belong for easier maintenance.

1.       Model is responsible for interacting with the database and provides the responses to the controller.
2.       Views represent the user interface of your application. Views are often HTML files with embedded Ruby code that perform tasks related solely to the presentation of the data.
3.       Controller is the main part in this kind of architecture where provide the glue between models and views. Controllers are responsible for processing the incoming requests from the web browser, interrogating the models for data, and passing that data on to the views for presentation.

 Components defined in the Model:

1.       Validations: This is one of the very essential components and it defines the validations that are being put up on the input type of stream like validate_presence_of, format_of, etc.
2.       Relationships: This is another type of component that describes the relationship between different types of components and it shows the relationship in the form of has_one, has_many, etc.
3.       Callbacks: This is essential when it comes to respond after the failure and it allows the application to have certain functionality during failure. This can be given as before_save, after_save, etc.
4.       Validation group settings: allow users to define the installed plugin settings.
5.       Active record association relationship: Allows current records to be actively having the relationship between one another.


Best practice for coder


1.Keep the controllers skinny – they should only retrieve data for the view layer and shouldn’t contain any business logic (all the business logic should naturally reside in the model).

2.Each controller action should (ideally) invoke only one method other than an initial find or new.

3.Share no more than two instance variables between a controller and a view.


1.Avoid altering ActiveRecord defaults (table names, primary key, etc) unless you have a very good reason (like a database that’s not under your control).

2.Group macro-style methods (has_many, validates, etc) in the beginning of the class definition.

3.Prefer has_many :through to has_and_belongs_to_many. Using has_many :through allows additional attributes and validations on the join model.

4.Beware of the behavior of the update_attribute method. It doesn’t run the model validations (unlike update_attributes) and could easily corrupt the model state.

Don’t Repeat Yourself
I’m sure most of you have heard of the DRY principle. It is something Rails has taken to heart, and I’m very glad it has. By not repeating yourself you can freely change something in one area of the program without worrying if you need to make the same change in another area. Not only that, but keeping the code DRY usually leads to better design.

Sometimes it is difficult to find duplication in your code. If you find yourself making a similar change in multiple places, you should first remove this duplication so you only need to make the change in one place.

This principle should not only be followed in code, but in your database and other areas as well. If you are repeating logic or data in the database, consider changing the design so it is not repeated.

That said, there are times when repeated data is good. For example, if you are building a cart system, the price for the items in the cart should be stored in a separate field than the price for the product. This allows you to change the price of the product without effecting all previous orders.

Stick to the Conventions
Another extremely important practice taken up by the Rails community: stick to the conventions. From naming variables to structuring files, there are conventions on how to do these things in Rails. If you are unsure of the conventions, check out a Rails book or tutorial – most of them stick to the conventions.

The advantages of sticking to conventions are almost too numerous to count. In fact, it deserves its own article.

Optimize Later
Performance is a major concern for many people switching to Rails, and rightly so. It is true that Rails is generally slower than other web frameworks. However, it is very scalable, so do not worry about it at the beginning. If you are a large corporation that needs to handle thousands of requests per second, then you may have something to be concerned about, but for the majority of us performance does not need to be considered until near the completion of the application.Any optimization done early requires guessing. Instead you should wait until you know where the bottlenecks are. Optimizing usually requires extra/complex code, and you should keep the code as clean and simple as possible. Therefore, only optimize where necessary. Also, any performance testing should be done in the production environment, as this adds some optimizations which are usually turned off in the development environment.Above all else, don’t let fear of poor performance inhibit you from making good design decisions! There are usually good ways to optimize while still keeping the good design, but these ways are hard to see unless you have a good design already in place. In short, don’t worry about performance while designing.

Humans First
Code for humans first, computers second. In other words, make the code as readable as you can. Most code should be understandable without comments.

How do you make the code more readable without comments? Rename variables, move code into classes/methods, etc. Try to give variables and methods concise, yet descriptive names. Do not abbreviate the names unless the abbreviation is very common.

Test Driven Development
You’ve heard it said: “Rails makes testing easy, so you don’t have any excuses not to do it.”. Well, in my opinion, testing is never easy – it is just easier in Rails.

Seriously, if you have not tried test driven development, give it a go. Automated tests are a godsend!. It will take some time to get used to testing, but the benefits are far worth it.

Re-factoring ties all of the things in this list together. Simply put, if you want to become a better programming, learn Refactoring. Normally the first time you write a piece of code, it is messy. Whatever you do, don’t leave the messy code as is. Even if it works correctly, it will be a headache to maintain. You should take some time to clean up the code, make it readable, and improve the design.