CODEWITHSUNDEEP
ruby-on-railsrubymodel-view-controller
LuckyLuke
LuckyLuke

Reputation: 49097

Controllers in Rails app

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?

Upvotes: 1

Views: 199

Answers (2)

Aliaksei Kliuchnikau
Aliaksei Kliuchnikau

Reputation: 13739

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.

Upvotes: 2

user229044
user229044

Reputation: 239501

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.

Upvotes: 0

Related Questions