We are writing a system with a sort of quasi-MVC structure (it was never stated as that, but that's what it is). I'm building up a full knowledge of the system and the controller will have to make calls to me to update it; they system itself is something similar to a graph.

We need to have a sense of a path between multiple nodes, and a way to identify the original node. I receive connections between two nodes in my original graph building, so knowledge of the full path, and the origin node, is not read in directly but obviously can be inferred once I finish building the graph.

My instinct was to write a basic path tracing sort of logic into my model. Every new edge we would infer the path's that exist and any original input nodes by tracing the path forward and backwards as appropriate. Tracing the path forward or backward does require a bit more knowledge of a system the connection between edges and nodes are a little more complicated then just edge 1 connect node A to B.

My question is, would doing this still be within the realm of the model? If I do all this path tracing, determining input nodes, identifying paths etc am I doing too much work which I should really be storing in the controller for easier modification later? I need to have some tracing capability to build the original graph before the controller is even initialized, but of course I could have the controller provide methods I call to do path tracing and the like an use the controller implementation when building the graph. I don't think the logic for the graph itself will change, only the way we use it for tasking, and doing things in the model makes it easier because the model can modify it's quasi-immutable objects directly while I'm not allowing the controller to do that without calls to the model (package scope variables).

2 Answers 2


Try to fit as much in the model as you can. Controllers are just for business actions, which are usually just variations of CRUD (create, read, update, delete). Models are for doing the advanced logic. For example, business requires that I view the path from A to B. The controller action for viewing a path would tell the model to find and trace the path for it. Then the controller would pass the data back to the view. Controllers mostly just pass data back and forth.

Here's a good analogy: http://nuts-and-bolts-of-cakephp.com/2009/01/06/another-way-to-think-about-mvc/. It's for CakePHP, but it should be true for all MVC.


Your model contains information that your view needs to display. This includes:

  • Data bound fields
  • Various results
  • Generated text

In your context, consider the model to be populated with data that is needed to be displayed from within the view.

With regards to the controller, an action in a controller does the following:

  • Perform any entry validation
  • Perform any business logic
  • Populate the model
  • Return the view, populated with the model.

The exception to the above is for languages that support annotations where you can have your validation on model fields.

My question is, would doing this still be within the realm of the model?

Potentially. It's likely to be a poll type answer, but in my opinion it is acceptable to have methods within a model that transforms data already present within the model. It should be purely transformative, and not have any external consequences.

  • 1
    What? The controller performs business logic?! Apr 2, 2013 at 6:30
  • @FlorianMargaine I typed this out in haste. The clarification should be that simple validation is performed in the model, whereas complex business logic dependant on different entities is typically performed in a controller based on an action.
    – Sam
    Apr 2, 2013 at 12:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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