CODEWITHSUNDEEP
ruby-on-railsmodel-view-controllerarchitecture
mack
mack

Reputation: 2965

MVC Application and Controller Design

I am relatively new to MVC and very new to Ruby on Rails. I've been going through Michael Hartl's excellent Ruby on Rails Tutorial for the second time and I have a question about application architecture. In chapter three he creates some static pages with actions from the same controller. Is this common in MVC architecture?

How do you determine between which pages should have the same controller and which pages should have their own individual controller? I assume that customers and contacts would have their own controller, but what about something like a dashboard or contact page, could they maybe go to the same controller?

Upvotes: 2

Views: 59

Answers (1)

Francesco Belladonna
Francesco Belladonna

Reputation: 11689

Actually, static pages aren't really about MVC, think about it: they are static, so they don't have business logic. Basically you'll end up with a VC instead of MVC (the model won't exist).

Usually, for static pages only, unless they need some special routing, you would go with a single controller and a bunch of actions, the direct consequence would be having a directory structure like

views/static_pages/<youstaticpage>.html.erb

That's quite nice, especially if your static pages are really static, so you end up with a maximum of ~10 pages.

The moment you need to pull data from the database, I suggest to extract that page into its own controller. So for example if you store website email/phone/address/whatever in a location and you need to fetch and use it in your About page, I suggest to create your AboutController and handle everything through it.

In this way you'll keep the StaticPagesController very clean. That being said, if you want to strictly stick with MVC, you should have one controller per static page, but would be really worthless in this case. Extract the code when you need it, it will still be very easy: the moment you don't have a simple page, extract it into its own controller.

One important thing I learned from POODR is that code must be good enough. In addition, you should start refactoring when it's needed, over-engineering it's an ugly beast. Believe me, I love over-engineering stuff.

Upvotes: 1

Related Questions