MVC Design Pattern

Question

I have read a lot about MVC design pattern, but some of the things are still unclear to me. I know that "Model" is for data and business logic, "View" is for presentation and "Controller" is for using "Models" and providing "Views" (i.e. C is the communication channel between M and V).

Now, I have the following problem I want to solve:

Problem: The web application takes as input, a list of Nodes from a user. Then, a Model is used to make a Graph (i.e. Data Structure Graph and not x-y graph) out of those nodes (using a database).

I then use Dijkstra's algorithm to find out the shortest path from a starting node to an ending node in that graph. Do I use the Dijkstra's algorithm in the Model or the Controller?

I think I should use the Model layer because the "shortest path" itself is data.

But sometimes, I think I should put it in the Controller because it uses the Models (Graph and List of nodes) to do something.

Can anyone give me the right answer? For now I am going to implement Dijkstra's algorithm in the model layer.

Answer 1

Yes you are right. You should put your Dijkstra's algorithm in model. The reason is that you may use a different algorithm to find shortest path tomorrow, so in that case you need not change your controller, just change the logic of class that implements the algorithm. And the outcome of the this algorithm should be incorporated in view.

Answer 2

The question is why the controller and not the model. Its a design question more than a coding question. It will work on controller and model. But if you need more than one controllers in future (for example use different algorithm's for shortest path), and you need your model to choose a controller at runtime, then it should be in the controller. If the algorithm "controllers" something else, then it should be in the model. May be you want to use shortest path using just this one algorithm, but in future you want to use different types of data. So then the data manipulator should be in the controller.

In short think future and design, and dont put it in the controller only because its good, do it because that you need the "change" to be the algorithm.

Change is the key here. What in future do you expect to change as new features are added to the product.

Answer 3

Personally, I would put algorithms into the controller part of the application, and use the strategy pattern to have the controller select the appropriate algorithm at runtime. If you have only one algorithm so far, then only that one algorithm is chosen with the strategy pattern.

This way, your model solely represents the state of the application and stays clear of any business logic. Furthermore, because of the strategy pattern, your controller stays independent of the specific algorithm implementation and you can extend your application to use other algorithms in the future relatively easily.

If you are sure that the application does not need to be extensible to use other algorithm implementations, you could do it without strategy pattern, because it could be seen as overengineering then.

Answer 4

Well, if you read Head First Servlets and Jsps, you will find that your logic is best kept in Model. Why I say so: If tomorrow you think of changing View Layer of your application, I you should have model ready to do it. For instance:The beauty of MVC is it gives you power of flexibility. Tomorrow I want my application want to run from desktop to web or vice a versa. I can have all my logic separately written. Strategy Design Pattern is good to go for extensibility but then it again want you to have you logic written in Model.

Answer 5

MY personal suggestion is that Go with the controller part because if you use the model part it will increase the execution time because after all model will be control by controller call

and for the sorest path algorithm there is no any database modification we have to just play with the data based on the algorithm

so my personal feel go with the controller instead of the model

thanks