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

2 回答 2

2

问题 1,2,4

我的观点是，你应该只应用任何类型的设计模式，并且只有在你真的需要它的时候。仅仅是因为设计模式毕竟并不容易。它们会给您的解决方案增加复杂性，但它们也会为您提供（通常）为特定类型的问题建立和工作解决方案的好处。

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

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

我希望这应该回答你的问题1和2。

对于问题 3：

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

MVC 帮助开发人员

  • 作为在应用程序源代码中导航时的方向。考虑在一个源文件中包含 3000 行代码的应用程序，然后让 4 个开发人员同时处理它。乱七八糟的，对吧？当拥有一个通常也使用路由等的 MVC 应用程序时......您通常已经通过查看 url 中的路由知道相应控制器位于源代码中的位置以及您应该把手放在哪里
  • 以便于测试。在应用单元测试实践时，关注点分离总是有益的，因为您可以更轻松地测试您的控制器，因为它不直接耦合到数据或表示性内容（如 HTML 代码等）。顺便说一句，你绝对应该对你的 JavaScript 代码进行单元测试，绝对！！
  • 维护：这是前面几点的结果

I'm not sure which kind of figure you intend by "tester". If he writes automated tests at the unit or acceptance level, then the benefits from before pretty much hold as well. If he's testing the app as a whole in the sense of navigating around, taking the app as a black box by testing its reaction to different kind of inputs, then MVC doesn't really play a big role for him. It's like for the end-user.

So I hope I was able to clarify some things for you. But as said, never just follow a pattern because people follow it but only 'cause it gives you any kind of benefits.

于 2013-01-12T11:10:28.927 回答
-1

MVC 用于构建您的代码，尤其是在您大量使用客户端渲染的情况下。如果没有结构，您的代码会很快变得复杂。

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

  1. 如果您有明确定义的代码结构，它有助于更​​快地浏览代码。
  2. JS MVC 框架最适用于您拥有复杂系统并且希望通过使用 AJAX 和部分页面重新加载或更新来提供更好的用户体验的情况。通常你不会将 MVC 用于个人网站、博客或类似的东西......
于 2012-12-10T09:20:40.767 回答