web应用程序不像一个普通的网页，他们更倾向于与用户的交互并且需要实时与后端服务器通信。如果你没有使用MVC框架来处理，这样会最终会让你写出一些编写混乱、非结构化、不可维护、不可测试的代码。为了避免“spaghetti”式的代码，那么JavaScript开发人员必须首先要了解这种模式提供了什么东西。这就可以看到这些框架能够让我们做什么哪些不同的事情。 使用JavaScript构建一个单页面应用程序的时候，不管是否拥有一个复杂的用户界面或者只是为了减少HTTP请求的数量，你可能会发现自己写的很多可以组成一个MV *框架的代码。刚开始的时候，使用自己想出来的方式来避免“spaghetti”式代码写一个应用框架并不是一件很难的事情，但是写出像Angular/Backbone这样的代码水平那就不太可能了。 我们会发现有更多的人会倾向于构建一个应用，而不是试着去将DOM操作库、模板、路由结合到一起。成熟的MV *框架通常不仅包括很多你发现自己写过的类似的功能代码，而且也包含了很多你曾经遇到并且已经解决了的问题。框架为你节省了很多时间，这就是框架不能低估的价值所在。 现在的浏览器提供了丰富的功能，变得越来越强大，这不仅让在JavaScript中构建成熟的web应用程序成为可能，而且这个方式越来越受欢迎。根据 HTTP Archive数据显示，今年部署的JavaScript代码规模增长了45%。
随着JavaScript的人气攀升， 我们的客户端应用程序比以前复杂得多 。一个应用程序开发需要多个开发人员合作，所以编写可维护和可重用代码在新的web应用程序时代是非常重要的。设计模式对于编写可维护和可重用的代码是很重要的。在过去几年时间里面，有很多JavaScript MVC框架已经被设计开发出来了，比如AngularJS，backbone.js， ember.js，还有很多其他的框架。虽然他们都有其独特的优势，但是每一框架都会鼓励开发人员遵循一定的形式以编写出更加结构化的JavaScript代码。 什么时候需要使用一个JS MV*框架如果你在构建一个应用，它的客户端有许多重量级的功能，用纯JavaScript很难应付，那你就应该考虑使用一个MVC框架。 如果选择错误，你将会错过MVC框架提供的功能，陷入重新发明轮子的境地。 要注意的是，如果你构建的应用在服务器端有很多重量级功能(即视图生成/展现逻辑)并且在客户端没有多少交互的话，这时你会发现使用MVC框架就像是杀鸡用牛刀。在那种情况下更好的选择是，使用一个更简单的、有少量附加功能的DOM操控类库。 下面这个列表并不完备，但是我们希望它能提供充分的理由帮你决定是否在你的应用中应该使用一个MVC框架:
满足这些情况的比较好的web应用的例子有Google Docs，Gmail或者Spotify。 客户机/服务器架构的web应用程序世界已经被改变，部分应用的逻辑已经被移到客户端。当我们需要以某种方式处理来自服务器的所有数据时，这里就描述这种情形。JS MVC框架鼓励把表现层逻辑从服务器端移动到客户端，实现了RIA（Rich-Internet-Apllication），传统web应用程序下的客户机/服务器架构和JS MVC下的客户机/服务器架构都基于web应用。
客户端一侧的MVC可以处理整个MVC栈。如果你同时使用服务器和客户端MVC，那么你会复制你的模型和路径。客户端一侧的MVC基本上允许你将你的服务器和客户端连接起来。为什么你的服务器要发送视图层？为什么不发送以json为格式的模型并加载它到客户端一侧，让客户端去渲染视图。你甚至可以在将来为其规定路由。为什么服务器要处理路由？客户端可以做这个。仅仅允许客户端去访问你的RESTful数据库就行，并且你不需要任何服务器端的MVC。 较流行的一种包含客户端服务端的模式是 后端RESTful API 通过 JSON发送数据模型 客户端使用MVC模式 处理应用. Client-side MVC with server-side RESTful API
Data Flow
上一篇：77%的IT业人员拟继续学习IT知识以防落伍下一篇：Go语言的依赖注入
 最新评论 |
