Controllers in Rails app

Question

Is the purpose of controller to provide actions that manipulates a model and updates a view? Does one model have exactly one controller that provides methods that manipulates it? Or does one controller have methods for multiple models?

All articles I find is what a controller is in terms of it is "here you put the business logic", not when to separate it into multiple controllers, what it does or what it belongs to.

Could somebody please explain?

Business logic doesn't really belong in controllers, though. — Dave Newton, Feb 06 '12 at 15:17

Aliaksei Kliuchnikau · Accepted Answer · 2012-02-06T19:08:00.677

2

Controller provide actions that bind view and model and it should not contain business logic, in should contain presentation logic/application logic. Generally speaking MVC is a view-organization architecture pattern and there are different patterns/approaches for organization of business logic layer/data access layer/services layer etc (all this is hidden behing Model in the MVC terminology).

MVC pattern does not tell you how to organize your Model, it only states that Model should contain the business logic. Because of this you don't have to build one-to-one relations between Model and Controller, it really depends on your system design and your application logic.

UPDATE

Model will contain logic that is always true for the domain of knowledge (business logic) and controller will contain logic, that may be specific for the part of an application (application logic, presentation logic). Controller usually parse user input, invokes Model methods, prepare and pass result to View. Controller should be thin. With all business logic in the Model it may be easy reused in the future.

edited Feb 06 '12 at 19:08

answered Feb 06 '12 at 15:29

Aliaksei Kliuchnikau

13,589
4
59
72

So if the procedure of saving the Question model as admin instead of an user it is the model responsibility to know that not the controller? The controller only invokes this method? – LuckyLuke Feb 06 '12 at 18:34
@Pjotr, I updated my question with clarification for my general logic separation approach. Regarding your question I think determine user role - Model responsibility, save user information - Model responsibility. Bind user and question together - depends on the application domain of knowledge. It may be Model responsibility, but likely to be Controller responsibility (application logic). – Aliaksei Kliuchnikau Feb 06 '12 at 19:14
So what is the difference between business and application logic? I though they were the same – LuckyLuke Feb 06 '12 at 19:47
@Pjotr, The difference between these terms is somewhat abstract and usually it is hard to divide them. You can read about application vs business logic in [this good answer](http://stackoverflow.com/a/2630793/158689). In your example 'question' is likely *Q&A* business domain concept and 'website admin' is an application-specific term. – Aliaksei Kliuchnikau Feb 07 '12 at 10:00
Sorry for late response. I will accept your answer but what do you mean that there don't need to be one-to-one relation between Model and Controller? So Controller is basically just the code that binds the model and view together and it contains the logic for that, but all logic that belongs to your business should be in the Model? – LuckyLuke Feb 09 '12 at 07:56
@Pjotr, by one-to-one relations I meant situation when Controller operate on a single Model class (Create-Read-Update-Delete logic). I wanted to say that Controller may operate on several different Model classes. – Aliaksei Kliuchnikau Feb 09 '12 at 08:16

score 0 · Answer 2 · answered Feb 06 '12 at 15:15

Is the purpose of controller to provide actions that manipulates a model and updates a view?

Yes

Does one model have exactly one controller that provides methods that manipulates it?

Not necessarily

Or does one controller have methods for multiple models?

They may, but again, not necessarily

All articles I find is what a controller is in terms of it is "here you put the business logic", not when to separate it into multiple controllers, what it does or what it belongs to.

There are no hard-and-fast rules. Keep your methods small, and limit the scope of concern for your actions. There will be times when an action must necessarily touch multiple models. Nobody can give you absolute rules for when to do this, especially in such a general case.

In short, it depends entirely on context and what you're trying to do.

Controllers in Rails app

2 Answers2