Basic MVC question

Rails
1

Hello!

I’d like to ask a simple controller design question regarding the MVC
pattern. It seems that most of the tutorials follow the
one-controller-per-table pattern. Books like AWDWR however use more
advanced approach. Unfortunalty AWDWR doesn’t provide an answer how to
choose how many controllers to have and what methods to be included.

My question is how do you choose how to break the logic into controllers
and how you solve cases when the process is not oblivious (for example
if you have
two controllers using the same model).

Thanks

2

Winter M. wrote:

I’d like to ask a simple controller design question regarding the MVC
pattern. It seems that most of the tutorials follow the
one-controller-per-table pattern.

Could you cite one? That’s not MVC. An MVC Controller is like an
old-fashioned
telephone operator, with a patchboard and a bunch of cabled plugs. The
operator
plugs any set of models into any set of views.

Books like AWDWR however use more
advanced approach. Unfortunalty AWDWR doesn’t provide an answer how to
choose how many controllers to have and what methods to be included.

My question is how do you choose how to break the logic into controllers
and how you solve cases when the process is not oblivious (for example
if you have
two controllers using the same model).

Write unit tests for everything, and refactor early and often.

When you refactor, obey the “DRY” principle. (Don’t repeat yourself.)
Merge any
shared code together. So two controllers using the same model will call
the same
methods on it.

–
Phlip

3

That’s an unfortunate side-affect of the way MVC in Rails is presented.
Controllers only contain flow logic. They handle requests and deliver
responses.

Models have a 1:1 relationship with tables, but models can also be
table-less.

Models should contain your business logic. Saving, calculating,
validations,
etc. Controllers should do nothing but pass requests to models and
render
views. If you find yourself doing anything more than that in a
controller,
then you’ve got refactoring to do.

Buckblog: Skinny Controller, Fat Model sums
it
up nicely.

On Mon, Mar 3, 2008 at 12:50 PM, Winter M. <

4

On Mon, Mar 3, 2008 at 1:19 PM, Brian H. [email protected] wrote:

That’s an unfortunate side-affect of the way MVC in Rails is presented.

Sorry, that should have read
“That’s an unfortunate side-affect of the way MVC in Rails is presented
in
many books and tutorials.”

My apologies.

5

Winter M. wrote:

Hello!

I’d like to ask a simple controller design question regarding the MVC
pattern. It seems that most of the tutorials follow the
one-controller-per-table pattern. Books like AWDWR however use more
advanced approach. Unfortunalty AWDWR doesn’t provide an answer how to
choose how many controllers to have and what methods to be included.

My question is how do you choose how to break the logic into controllers
and how you solve cases when the process is not oblivious (for example
if you have
two controllers using the same model).

Thanks

Model should have all the business logic.
In fact, ideally that’s where most of code should be…the model.

Controller is just like a control center that bridges between model and
views.
Ideally it should just have the CRUD (Create, Read, Update, Delete)
operations.

Views is all client side presentation stuff.

Putting most of the code and business logic in the model also isolates
it from the views…that’s desired…

So, bottom-line controller should have the minimum code.

Watch DHH’s railsconf keynote on Rails 2.0 RESTful architecture.

Be sure to download the pdf before you watch it.