Reputation: 49097
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
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
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