The MVC Architecture (MVC)

I am happy to know that you all get a good knowledge about the rails Introduction post.So lets move to the working principle action in rails application Model–View–Controller (MVC) is a software architecture,currently considered an architectural pattern used in software engineering. The pattern isolates "domain logic" (the application logic for the user) from input and presentation (UI), permitting independent development, testing and maintenance of each.For instance, as depicted in the figure below, you may refer to "controller" as "input", "model" as "processor" or "processing" and "view" as "output". So in other words, controller receives the input, passes it to the model for processing, or to the view for output. So MVC benefits include:

• Isolation of business logic from the user interface

• Ease of keeping code DRY

• Making it clear where different types of code belong for easier maintenance

Let Us explain each in detail mentioning each functionalities

1) Model

A model represents the information (data) of the application and the rules to manipulate that data. In the case of Rails, models are primarily used for managing the rules of interaction with a corresponding database table. In most cases, one table in your database will correspond to one model in your application. The bulk of your application’s business logic will be concentrated in the models.

2) View

The view renders the model into a form suitable for interaction, typically a user interface element. Multiple views can exist for a single model for different purposes. A viewport typically has a one to one correspondence with a display surface and knows how to render to it.

3) Controller

The controller receives input and initiates a response by making calls on model objects. A controller accepts input from the user and instructs the model and viewport to perform actions based on that input.

So the steps involved in the working of MVC is as follows

• The browser makes a request, such as http://rubyonrailslink.blogspot.com/2010/09/what-is-rails.html

• web server (mongrel, WEBrick, etc.) receives the request. It uses routes to find out which controller to use: the default route pattern is “/controller/action/id” as defined in config/routes.rb. In our case, it’s the “video” controller, method “show”, id “15″. The web server then uses the dispatcher to create a new controller, call the action and pass the parameters.

• Controllers do the work of parsing user requests, data submissions, cookies, sessions and the “browser stuff”. They’re the pointy-haired manager that orders employees around. It gives orders without knowing (or caring) how it gets done. In our case, the show method in the video controller knows it needs to lookup a video. It asks the model to get video 15, and will eventually display it to the user.

• Models are Ruby classes. They talk to the database, store and validate data, perform the business logic and otherwise do the heavy lifting. In this case, the model retrieves video 15 from the database.

• Views are what the user sees: HTML, CSS, XML, Javascript, JSON. They’re the sales rep putting up flyers and collecting surveys, at the manager’s direction. Views are merely puppets reading what the controller gives them. They don’t know what exactly happening in the back room. In our example, the controller gives video 15 to the “show” view. The show view generates the HTML: divs, tables, text, descriptions, footers, etc.

• The controller returns the response body (HTML, XML, etc.) & metadata (caching headers, redirects) to the server. The server combines the raw data into a proper HTTP response and sends it to the user.