in MVC/MVP/MVPC where do you put your business logic?

Question

in the MVC/MVP/MVPC design pattern where do you put your business logic? No, I do not mean the ASP.NET MVC Framework (aka "Tag Soup").

Some people say you should put it in the "Controller" in MVC/MVPC or "Presenter". But, others think it should be part of the Model.

What do you think and why?

Luckey

In my opinion your question is missing some context. Do you mean MVC as an application wide pattern or as an UI pattern? – Rriocard

Answer 1

This is how I see it:

The controller is for application logic; logic which is specific to how your application wants to interact with the domain of knowledge it pertains to.

The model is for logic that is independent of the application. i.e. logic that is valid in all possible applications of the domain of knowledge it pertains to.

Hence nearly all business rules will be in the model.

I find a useful question to ask myself when I need to decide where to put some logic is "is this always true, or just for the part of the application I am currently coding?"

Revitalize

+1: User interface is View/Controller -- it changes. Model is the essence. – Illiberal

This is sound advice. However, when you have multiple views depending on the same business logic, you want to avoid duplicating that logic in both controllers/presenters. – Unwarranted

Answer 2

The way I have my ASP.NET MVC application structure the workflow looks like this:

Controller -> Services -> Repositories

The Services layer above is where all the business logic takes place. If you put your business logic in your Controller layer, you lose the ability to re-use that business logic in other controllers.

Limemann

@Kevin When you say Services layer, do you literally mean SOA as in something like WCF/data services/etc.? Or is it implemented as just more code/classes that sit between your controller and repository? – Nevarez

@Nevarez I mean just another project that sits between my controller and repository. – Limemann

What do you mean by repositories in this case? Is this the layer with your models? – Fourdrinier

Answer 3

I don't believe it belongs in the controller, because once it's embedded there it can't get out.

I think MVC should have another layer injected in-between: a service layer that maps to use cases. It contains business logic, knows about units of work and transactions, and deals with model and persistence objects to accomplish its tasks.

The controller has a reference to the service that it needs to fulfill its use case. It worries about unmarshalling requests into objects the service can deal with, calls the service, and marshals the response to send back to the view.

With this arrangement, the service is usable on its own even without the controller/view pair. It can be a local or remote object, packaged and deployed any way you wish, that the controller deals with.

The controller now becomes bound more closely to the view. After all, the controller you'll use for a desktop is likely to be different than the one for a web app.

I think this design is more service-oriented.

Manned

Really like this reply almost 10 years later. I'm still often faced with huge models and/or huge controllers with code that can't be re-used and tightly coupled. MVC has made a lot of things better, but it appears to be holding people back in a way. – Miserable

Answer 4

Put your business logic in domain and keep your domain separte. I prefered Presenter -> Command (Message command use NServiceBus) -> Domain (with BC Bounded Context) -> EventStore -> Event handler -> Repository (read model). If logic is not fit in domain then use service layer.

Please read article from Martin fowler, Eric Evan, Greg Young and Udi dahan. They have define very clear picture.

Here is article written by Mark Nijhof : http://elegantcode.com/2009/11/11/cqrs-la-greg-young/

Libb

The link to the article no longer exists. – Bremerhaven

@Bremerhaven please use web.archive.org - web.archive.org/web/20100124174150/http://elegantcode.com:80/… – Goetz

Answer 5

By all means, put it in the model!

Of course some of the user interaction will have to be in the view, that will be related to your app and business logic, but avoid this as much as possible. Ironically following the principle of doing as little as possible as the user is 'working' in your GUI and as much during 'submit' or action requests makes for a better user experience and usability, not the other way around. At least for line-of-business apps.

Wier

Answer 6

You can put it in two places. The Controller and in the Presentation layer. By having some of the logic in the Presentation layer, you can limit the number of requests back into the architecture which adds load to the system. Yeah, you have to code twice, but sometimes this is what you need for a responsive user experience.

I kinda like what was said here (http://www.martinhunter.co.nz/articles/MVPC.pdf)

"With MVPC, the presenter component of the MVP model is split into two components: the presenter (view control logic) and controller (abstract purpose control logic)."

Sporadic

i see that PDF as 'forced' and artificial on the splitting presenter and controller logic in the given example. i find the explanation given in the aviadezra.blogspot.com/2008/06/… more appropriate where view delegates control immidiately to the presenter, and the GUI changes regarding the action executed are encapsulated in the 'action-related-UI-change methods' and called after the action has been done. – Londrina

FYI I moved the article referenced to here continuity.kiwi.nz/Content/Articles/MVPC.pdf Cheers Martin. – Tombaugh