Jophine
Jophine

Reputation: 594

mvc architecture ruby on rails

In Ruby on Rails, MVC architecture is designed in such a way that, the controller will receive the request and talk to model to receive data and again controller will talk to view to generate html. Now my doubt is, why should model reply to controller and then controller to view, rather than model directly replying to view to generate html. Why was it not designed in that way?

Can someone please clarify? Thanks in advance.

Upvotes: 1

Views: 857

Answers (1)

Sergio Tulentsev
Sergio Tulentsev

Reputation: 230296

... model directly replying to view to generate html ...

And what if tomorrow you need to generate JSON? And then XML? And other 10 formats? Will you update model each time?

Model, View and Controller have distinct responsibilities.

  • Model - business logic. Saves and loads data.
  • View - renders data in a specific format.
  • Controller - mediator between the two. Parses requests, does authentication/authorization, asks model for data, calls appropriate view with that data.

There should be no business logic in views, rendering in models, etc. This helps for better, cleaner code.

In my hypothetical example, you just need to add a view that can render JSON representation of data. And, probably, add one or two lines to controller (often you don't have to). Model is left unchanged. Its concern is data persistence, not data presentation.

Upvotes: 8

Related Questions