Question

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)?

Answer 1

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.