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