CODEWITHSUNDEEP
asp.net-mvcasp.net-mvc-3asp.net-mvc-4
RobVious
RobVious

Reputation: 12915

Should business logic ever be in the model? (MVC4)

I have a class called "Stores" in my MVC app that has a class called "IsInCompliance" which depends on the values of several other fields. The logic would go through and say "if this, this, and this is true, then IsInCompliance is true".

Should this belong in the model definition, or would this logic be better placed in a service layer or controller? I figure I have four options:

  1. Logic contained in a method within the model
  2. Logic contained in a controller that writes back to the model
  3. Logic contained in a Service that the model calls
  4. Logic contained in a Service that the controller calls

Which is best? If 3 is the best, isn't there a circular dependency there (since my model project depends on the services project, which depends on the model project)?

Upvotes: 3

Views: 1150

Answers (5)

Philip Tenn
Philip Tenn

Reputation: 6073

This is a matter of preference/style, but I have always believed that methods that are germane to the Model object belong in that object.

Take this as an example (I'm coding on the fly without an open VS.NET instance, so please forgive any syntax errors, just trying to use this as a vehicle for communication): 

public class Person 
{
    public Int32 Age { get; set; }

    public bool IsEligibleToEnterLegallyBindingContract() 
    {
        return Age >= 18;
    }
 }

I would assert that a model object that contains methods that introspects its own properties and is not dependent on messages and/or properties of other model objects is good object design and a good modeling approach in an MVC environment.

Update I had a discussion with a colleague regarding this, and he pointed me toward the Anemic Domain Model, an excellent article by Martin Fowler. I read this article several times after my colleague recommended it.

The closing paragraph from Mr. Fowler's article (this is a direct quote from martinfowler.com and credit is acknowledged and given to that site):

"In general, the more behavior you find in the services, the more likely you are to be robbing yourself of the benefits of a domain model. If all your logic is in services, you've robbed yourself blind."

Upvotes: 3

Rik Leigh
Rik Leigh

Reputation: 1328

I guess it depends on your coding style.

Either option 1, or option 4 is correct depending on who you ask.

For something like this, i think option 1 is correct.

If IsInCompliance only depends on the value other properties in the model then it should be in the model.

If the value of IsInCompliance depends on other classes then yes it should be in a service layer.

Moving stuff like this to a service layer results in an Anemic Domain model where your model classes end up just being dto's

In object oriented design, this is considered an anti pattern.

There is still plenty of stuff that needs to be in a service layer, i just don't think this is one of them.

Upvotes: 0

Dimitar Dimitrov
Dimitar Dimitrov

Reputation: 15138

Usually I perform actions on the Model rather than IN the Model, however it is sort of a personal preference. I would (in your case) write the logic in the Service layer, then do a coordination call from the Controller that would work on the Model. That said however, I believe some people refer to this as an Anemic Domain Model.

I don't think any of the approaches are wrong, but I personally would go for Number 4.

Upvotes: 0

Ulises
Ulises

Reputation: 13419

MVC is all about separating concerns. Keep it that way. Separate your logic from your data by placing your business logic in a separate class (layer).

Upvotes: 0

Ofer Zelig
Ofer Zelig

Reputation: 17470

Number 4 is the correct approach.

Controllers should act as a thin "traffic control" layer and delegate all logic to a service layer beneath them (or if it's not too obvious logic, to a business layer - but that's a different architectural question).

Your model should generally be a pure POCO structure, with optionally micro-logic of things that are internal to the data model. For example, ID generation and data integrity operations.

Most of your logic (for relatively simple / CRUD-based apps) should generally reside in the Service Layer.

Upvotes: 3

Related Questions