In an MVC framework i have often heard that use business logic in a model. But i think using the business logic in controller would run faster as view is directly connected to controller. I want to know what are the advantages of using a business logic in model?
The key is:
Separation of concerns
In an ideal world you want any given piece of code to do one thing and to do that well. So you want to try and avoid mixing up display logic and business logic and storage logic and everything else.
On contemporary server hardware performance just shouldn't be an issue unless you're doing seriously funky stuff and then you don't want to have bound up in the user interface layers because you can't then attempt to deal with the performance issues in isolation.
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
Decoupling user interface from the model makes it easier to write tests against just the model. You just test against the core functionality, without having to worry about User Interface getting in the way (which you may test as well, and there are ways to do that, but this is not what you are asking :).
The model manages the behavior and data of the application domain, responds to requests for information about its state (usually from the view), and responds to instructions to change state (usually from the controller). In event-driven systems, the model notifies observers (usually views) when the information changes so that they can react.
The view renders the model into a form suitable for interaction, typically a user interface element. Multiple views can exist for a single model for different purposes. A view port typically has a one to one correspondence with a display surface and knows how to render to it.
The controller receives user input and initiates a response by making calls on model objects. A controller accepts input from the user and instructs the model and a view port to perform actions based on that input.
also see the screenshot
Please read carefully and reply me if you have any Query regarding this @shayan