javascript - 为什么我们需要javascript mvc？

Question

1. 什么时候会使用 Javascript MVC？我的意思是为什么有一个需要 JS-MVC 吗？
2. 是否仅仅是因为这种设计模式在其他语言中很出名，代码维护、可读性和许多网络应用程序都在客户端交付？
3. 它如何帮助开发人员、测试人员和最终用户简化他们的任务 ?
4. 任何 JS-MVC 最适合的用例以及它最适合的任何情况完全不需要？

Answer 1

问题1、2、4

我的观点是，您应该仅在确实需要时才应用任何类型的设计模式。很简单，因为设计模式毕竟不容易。它们会增加您的解决方案的复杂性，但它们也会为您提供(通常)针对特定类型问题建立和工作解决方案的好处。

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

但在工作中，我们创建单页应用程序，我们有 2-5 名开发人员同时处理一个项目，项目总计 500 天。在这样的环境中，事情会很快变得复杂，如果您不遵循任何类型的适当结构，您就会迷失方向。

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

对于问题3:

最终用户希望获得质量更好、错误更少的应用程序，但通常他甚至不应该注意到(也不关心)应用程序的底层架构。

MVC 帮助开发者

• 作为在应用程序源代码中导航时的方向。考虑一个应用程序在一个源文件中包含 3000 行代码，然后有 4 个开发人员同时处理它。一团糟，对吧？当拥有一个通常也使用路由等的 MVC 应用程序时......您通常已经通过查看 url 中的路由知道相应 Controller 位于源代码中的位置以及您应该动手的位置
• 以便于测试。在应用单元测试实践时，关注点分离总是有益的，因为您可以更轻松地测试您的 Controller ，因为它不直接耦合到数据或表示性内容(如 HTML 代码等)。附带说明一下，您绝对应该对您的 JavaScript 代码进行单元测试，绝对!
• 维护:这是前面几点的某种结果

我不确定“测试者”指的是哪种数字。如果他在单元或验收级别编写自动化测试，那么之前的好处也几乎适用。如果他在四处导航的意义上将应用程序作为一个整体进行测试，通过测试它对不同类型输入的 react 将应用程序视为一个黑盒子，那么 MVC 对他来说并没有真正发挥重要作用。这就像最终用户。

所以我希望我能够为您澄清一些事情。但如前所述，永远不要因为人们遵循某种模式而遵循它，而只是因为它给你带来了任何好处。