我已经阅读了很多关于 MVC 设计模式的内容，但有些东西我仍然不清楚。我知道“模型”用于数据和业务逻辑，“视图”用于演示，“控制器”用于使用“模型”并提供“视图”（即 C 是 M 和 V 之间的通信通道）。
现在，我想解决以下问题：
问题： Web 应用程序将来自用户的节点列表作为输入。然后，使用模型从这些节点（使用数据库）中制作一个图（即数据结构图而不是 x-y 图）。
然后我使用 Dijkstra 算法找出该图中从起始节点到结束节点的最短路径。我是在 Model 还是 Controller 中使用 Dijkstra 算法？
我认为我应该使用模型层，因为“最短路径”本身就是数据。
但有时，我认为我应该将它放在 Controller 中，因为它使用模型（图形和节点列表）来做一些事情。
谁能给我正确的答案？现在我将在模型层实现 Dijkstra 算法。
【问题讨论】：
是的，你是对的。 您应该将 Dijkstra 算法放入模型中。原因是你明天可能会使用不同的算法来找到最短路径，所以在这种情况下你不需要改变你的控制器，只需改变实现算法的类的逻辑。 并且这个算法的结果应该被纳入视野。
【讨论】：
问题是为什么是控制器而不是模型。它是一个设计问题，而不是一个编码问题。它将适用于控制器和模型。但是如果你将来需要多个控制器（例如使用不同的算法来获得最短路径），并且你需要你的模型在运行时选择一个控制器，那么它应该在控制器中。如果算法“控制”了其他东西，那么它应该在模型中。可能您只想使用这一种算法来使用最短路径，但将来您想使用不同类型的数据。那么数据操纵器应该在控制器中。
简而言之，考虑未来和设计，不要仅仅因为它好而将其放入控制器中，而是因为您需要“改变”成为算法。
改变是这里的关键。随着新功能添加到产品中，您预计将来会发生什么变化。
【讨论】：
就个人而言，我会将算法放入应用程序的控制器部分，并使用策略模式让控制器在运行时选择合适的算法。如果到目前为止您只有一种算法，那么策略模式只会选择一种算法。
这样，您的模型仅代表应用程序的状态，并且与任何业务逻辑无关。 此外，由于策略模式，您的控制器独立于特定的算法实现，您可以相对轻松地扩展您的应用程序以在将来使用其他算法。
如果您确定应用程序不需要可扩展以使用其他算法实现，则可以不使用策略模式，因为这可能被视为过度工程。
【讨论】：
好吧，如果您阅读 Head First Servlets 和 Jsps，您会发现您的逻辑最好保存在 Model 中。 我为什么这么说：如果明天你想改变应用程序的视图层，我应该准备好模型来做这件事。 例如：MVC 的美妙之处在于它赋予了您灵活性的力量。明天我希望我的应用程序能够从桌面运行到网络，反之亦然。我可以单独编写所有逻辑。策略设计模式很适合可扩展性，但它又希望您在模型中编写逻辑。
【讨论】：
我个人的建议是使用控制器部分 因为如果你使用模型部分，它会增加执行时间，因为毕竟模型将由控制器调用控制
对于最坏的路径算法，没有任何数据库修改，我们只需要根据算法处理数据
所以我个人的感觉是控制器而不是模型
谢谢
【讨论】：