为什么我们需要javascript mvc？

Question

1. 什么时候可以使用Javascript MVC？ 我的意思是为什么需要JS-MVC？
2. 仅仅是因为这种设计模式在其他语言中很出名，因为代码维护，可读性好，并且许多Web应用程序都在客户端发布？
3. 它如何帮助开发人员，测试人员和最终用户简化任务？
4. 是否有最适合使用JS-MVC的用例，而根本不需要它的任何用例？

Answer 1

问题1,2,4

我的观点是，只有在确实需要时，才应应用任何一种设计模式。 仅仅是因为设计模式毕竟并不容易。 它们将为您的解决方案增加复杂性，但它们也将为您提供（通常）为特定类型的问题建立和使用解决方案的好处。

是否使用它们确实取决于您要构造什么以及它的复杂程度。 也就是说，我可能不会使用MVC模式来构造200行的jQuery插件，也许...

但是在工作中，我们创建了单页应用程序，其中有2-5个开发人员同时在一个项目上工作，这些项​​目的时间为500天。 在这样的环境中，事情会很快变得复杂，如果您不遵循任何适当的结构，就会迷路。

我希望能回答您的问题1和2。

对于问题3：

最终用户希望获得质量更好，错误更少的应用程序，但是通常他甚至都不应该（也不在乎）应用程序的基础架构。

MVC帮助开发人员

• 作为导航应用程序源代码时的方向。 考虑一个源文件中有3000行代码的应用程序，然后让4个开发人员同时对其进行处理。 一团糟，对不对？ 当拥有一个通常也使用路由等功能的MVC应用时...通常通过查看url中的路由就可以知道该地址，其中相应的控制器位于源代码中，应该放在哪里
• 便于测试。 在应用单元测试实践时，关注点分离始终是有益的，因为您可以轻松地测试控制器，因为它不会直接耦合到数据或表示形式的内容（例如HTML代码等）。 另外，当然，您绝对应该对JavaScript代码进行单元测试！
• 维护：这是前面几点的结果

我不确定“测试人员”打算使用哪种图形。 如果他在单元或验收级别上编写自动化测试，那么从中获得的好处也几乎可以成立。 如果他从导航的角度对应用程序进行整体测试，通过测试应用程序对不同种类输入的反应将应用程序视为黑盒，那么MVC对他来说实际上并不起作用。 就像最终用户一样。

所以我希望我能为您澄清一些事情。 但是，正如所说的那样，永远不要只遵循一种模式，因为人们会遵循它，而只是因为它会给您带来任何好处。

Answer 2

MVC用于构造代码，尤其是当您处理大量客户端渲染时。 没有结构，您的代码将变得非常复杂。

如果您只需要部分更新，而不必等待整个页面刷新，则最终用户的用户体验会更好。

1. 如果您具有明确定义的代码结构，则有助于更快地浏览代码。
2. JS MVC框架最适合用于具有复杂系统的地方，并且希望通过使用AJAX和部分页面重新加载或更新来提供更好的用户体验。 通常，您不会将MVC用于个人网站，博客或类似的东西...