Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question
    
If you put your business logic in the controller, what would be left in the model then? :) –  Dime Mar 19 '12 at 15:09
    
model interacts with the database and runs the query required... thats my opinion which might be wrong... –  Shayan Husaini Mar 20 '12 at 7:04

4 Answers 4

up vote 8 down vote accepted

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.

This separation provides a variety of benefits - testability (as suggested) is an important one (though to my mind it's almost a bonus), but also the fact that the code should be easier to understand at any given level and hence easier to maintain, that the business model/logic (in particular) is more portable (from web to native app) or that you can change the UX (say from MVC pages to a fully separated javascript app using a web API) - finally, if nothing else, the cummulative experience of a huge number of programmers tells us that it - separation of concerns - is a good thing.

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.

share|improve this answer
    
My concren is whenever end user uses our application it hits our controller so its better to validate the data according to business rules in a controller rather than validating in a model –  Shayan Husaini Mar 19 '12 at 11:34
2  
Its all the same code running in the same place. The overhead of object instantiation and the method calls should negligble or you're doing something seriously wrong. Whilst you shouldn't be blind to performance considerations they really shouldn't be something you worry about in the first instance (in the general case) and more importantly anything that is purely in code is unlikely to be a bottleneck. You will get far more value (and have more time to look at performance if needed) if you have a well structured application with appropriate automated tests –  Murph Mar 19 '12 at 12:05

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

share|improve this answer
    
if i am not wrong you are saying that it depends on the type of business rules and its developer who decide where to put the particular logic –  Shayan Husaini Mar 19 '12 at 11:51
  1. Testability.

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 :).

share|improve this answer
    
i didnt catch your point it would be good if you provide some details –  Shayan Husaini Mar 19 '12 at 7:24
    
I added some details, hope it helps :) –  Eugene Mar 19 '12 at 7:33

Model Concept....

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.

View Concept....

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.

Controller Concept...

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.

MVC

also see the screenshot

enter image description here

Please read carefully and reply me if you have any Query regarding this @shayan

share|improve this answer
1  
read my question carefully i haven't ask the concepts of mvc framework.... –  Shayan Husaini Mar 20 '12 at 10:38
    
first you have to clear your concept then ask Question –  Samad Mar 20 '12 at 10:41
    
your Question is belong to this Concept first you have to read carefully and reply me –  Samad Mar 20 '12 at 10:45
    
In the original MVC pattern the Controller does not direct the View, it only observes the view. –  kevin cline May 12 at 19:31

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.