MVC设计模式

Question

MVC设计模式

model-view-controller

4

我已经阅读了很多关于MVC设计模式的内容，但其中有些东西还不太清楚。我知道“Model”是用于数据和业务逻辑，“View”是用于展示，“Controller”是用于使用“Models”并提供“Views”（即C是M和V之间的通信渠道）。

现在，我有以下问题要解决：

问题：Web应用程序从用户那里获取节点列表作为输入。然后，使用一个Model将这些节点制成图表（即数据结构图表而不是x-y图表）（使用数据库）。

然后，我使用Dijkstra算法在该图表中找出从起始节点到终止节点的最短路径。我应该在Model层还是Controller层中使用Dijkstra算法？

我认为我应该在Model层中使用，因为“最短路径”本身就是数据。

但有时，我认为我应该把它放在Controller中，因为它使用Models（图表和节点列表）来完成某些操作。

有人能给我正确的答案吗？目前，我打算在Model层中实现Dijkstra算法。

- coolscitist

5个回答

4

问题是为什么选择控制器而不是模型。这是一个设计问题而不是编码问题。它可以在控制器和模型上工作。但如果未来需要多个控制器（例如，使用不同的算法来寻找最短路径），并且需要在运行时让模型选择控制器，则应该将其放在控制器中。如果算法“控制”其他内容，则应将其放在模型中。也许您想只使用这种算法进行最短路径，但是未来可能需要使用不同类型的数据。因此，数据操作器应该位于控制器中。

简而言之，考虑未来的需求和设计，不要只是因为好而将其放在控制器中，而是因为您需要进行“更改”以实现算法。

变化是关键。在未来添加新功能时，您希望发生什么变化？

- Siddharth

我将在模型中实现该算法。它其实只是一个大学作业。但这次，我不会让任何不良的编程习惯进入我的代码中。我正在对自己严格要求。 - coolscitist

1

@Robik，重要的是你要基于未来的“变化”而不是“这只是一个大学作业”来做出决定。如果你阅读《设计模式》一书，它们会强调“变化”。同时，他们建议示例仅为“指南”。记住，如果你编写了“易于更改”的代码，这意味着“更改不应该在未更改的区域中引起更多测试或导致未更改的区域出现缺陷”。那么你今天就编写了好的代码。因此，在决定何时/何处编写代码之前，请考虑“明天”的变化。 - Siddharth

1

好的。也许当我开始专业工作时，我会真正感受到事物的实际情况。 - coolscitist

1

个人而言，我会将算法放在应用程序的控制器部分，并使用策略模式使控制器在运行时选择适当的算法。如果你只有一个算法，那么只有该算法会被策略模式选择。

这样，你的模型仅代表应用程序的状态，清楚地呈现出任何业务逻辑。此外，由于策略模式，你的控制器保持独立于具体的算法实现，你可以相对容易地扩展你的应用程序以使用其他算法。

如果你确定应用程序不需要可扩展性来使用其他算法实现，那么你可以不使用策略模式，因为这可能被视为过度工程化。

- sdcr

1

如果你读过《Head First Servlets and Jsps》，你会发现最好将逻辑保留在Model中。 为什么这么说：如果明天你想改变应用程序的视图层，你应该已经准备好了Model。例如：MVC的优美之处在于它赋予了你灵活性的权力。明天我希望我的应用程序可以从桌面运行到Web或者反之。我可以将所有的逻辑单独编写。策略设计模式非常适合扩展性，但是它又要求你将逻辑编写在Model中。

- Shweta Gulati

0

我个人的建议是使用控制器部分，因为如果使用模型部分，它会增加执行时间，因为毕竟模型将由控制器调用控制

对于最短路径算法，我们没有任何数据库修改，我们只需根据算法操作数据

所以我个人认为应该选择控制器而不是模型

谢谢

- Saiyam Patel

有另一个回答我的问题，但我现在不知道它去哪了。它说，迪杰斯特拉算法应该在控制器中，其结果即最短路径应该是一个模型。我认为这是正确的答案。 - coolscitist

1

为什么控制器应该是一个通信渠道而不是实现逻辑的地方。实现应该在模型中。 - Tassadaque

我将在模型中实现该算法。 - coolscitist

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Ravi Khakhkhar · Accepted Answer

是的，你是正确的。你应该将你的Dijkstra算法放在模型中。原因是明天你可能会使用不同的算法来寻找最短路径，那么在这种情况下，你无需更改控制器，只需更改实现算法的类的逻辑即可。而且，这个算法的结果应该被纳入视图中。