First, it is almost every time a mistake to argue about the place of the business logic in terms of program speed (at least, when your model and controller layers are part of the same program with no network communication between them). If you have speed issues, you can optimize them in your model layer as well as in your controller layer.

Much more important than speed is typically the goal to give your programm a good structure, where you know where things are, where you can test things in isolation, where you avoid code repetition when the same part of business logic is needed twice, and so on.

Thus, the question for the best place should be guided by the question "what kind of business logic?"

• business logic controlling the user interactions of your views belong typically into a controller
• small parts of business logic dealing with primarily one business object typically belong to that object and so are best placed in the model. Example: having an object "Person" with attributes "FirstName" and "LastName", and you need to get the "full name" as concatenation of FirstName and LastName, then a property "FullName" of "Person" may be a good idea.
• for bigger parts of your logic, independent from your views, you should introduce separate controller classes.

Where exactly to draw the line is up to you. There is a long-lasting and open-ended discussion in the community about how much logic should be in the model and how much in controllers, see, for example, here: http://www.martinfowler.com/bliki/AnemicDomainModel.html

First, it is almost every time a mistake to argue about the place of the business logic in terms of program speed (at least, when your model and controller layers are part of the same program with no network communication between them). If you have speed issues, you can optimize them in your model layer as well as in your controller layer.

Much more important than speed is typically the goal to give your program a good structure, where you know about the responsibility of each component, where you can test things in isolation, where you avoid code repetition when the same part of business logic is needed twice, and so on.

Thus, the question for the best place should be guided by the question "what kind of business logic?"

• business logic controlling the user interactions of your views belong typically into a controller
• small parts of business logic dealing with primarily one business object typically belong to that object and so are best placed in the model. Example: having an object "Person" with attributes "FirstName" and "LastName", and you need to get the "full name" as concatenation of FirstName and LastName, then a property "FullName" of "Person" may be a good idea.
• for bigger parts of your logic, independent from your views, you should introduce separate controller classes.

Where exactly to draw the line is up to you. There is a long-lasting and open-ended discussion in the community about how much logic should be in the model and how much in controllers, see, for example, here: http://www.martinfowler.com/bliki/AnemicDomainModel.html