个人架构经验系列文章 - 前端架构

框架层面：近几年前端发展很快，前端之因此叫前端由于前端是已经能够独立成为一种职业了，js也再也不是十年前的玩具了，之前富客户端RIA的应用可能会用flash/flex或是silverlight，如今可使用js来完成大部分的功能，所以js做为一门前端的支撑语言也不只仅是进行的简单的编码，愈来愈多框架性的东西出现了。愈来愈多的开发模式转变为后端只是吐json的数据源，而前端作全部UI的事情。

　　MVC

　　MVC实现职责分离是很好的，大多数网站在后端都会引入MVC框架，对于一个前端负责全部呈现和前端业务逻辑的网站来讲，使用MVC框架也是颇有好处的。Javascript的MVC框架如今不少。每个框架其实都有其特色的，可是前端的MVC框架会和后端的有些不一样的。好比前端的MVC框架可能会作一些M和V元素的双向绑定，对于后端来讲每每是单向的比较多。经过引入MVC框架咱们可让同一个页面作不少事情，经过一个不刷新的页面实现一个应用程序的根基，还能够很清晰地进行MVC的分离而且突出M的概念，这是没有框架所办不到的。

　　通信

　　对于一个比较复杂的页面可能会有比较多的Javascript模块，若是要进行模块之间通信的话(好比一个页面有左边菜单和导航以及列表，左边菜单点选一级分类以后要通知导航加上去这项，而且通知列表从新读取数据并刷新，而后从导航删除这个选择的话要通知列表从新获取数据，通知菜单显示全部)。对于比较复杂的通信，若是把模块模块之间进行强耦合直接调用其它模块的函数的话是不利于可维护性的，我以为能够引入发布订阅机制，每个模块作了什么修改把信息发布出去，关心这个信息的人订阅这个信息，而且在回调函数里面作相应的操做就能够了。可使用Amplifyjs做为发布订阅的框架。

　　模板

　　对于前端来讲和后端同样一个比较麻烦的问题就是每每会在脚本里面把html也混在一块儿，我的以为是这样的，若是对于很是琐碎一些dom修改问题倒不大，若是是大块的html拼接的话，数据和html甚至是css混合在一块儿，那么代码的可维护程度很是差。此时能够考虑使用一些模板引擎来分离数据和表现，好比Twitter hoganjs。因为不少模板引擎，好比大胡子引擎不只仅是针对前端的，后端语言也有相应的引擎，所以甚至能够把模板放在文本文件中，前端后端共同使用一套模板引擎，也就是说如今的代码偏向于服务端渲染的那么就在后端使用模板，若是要之后改成客户端渲染了这套模板能够直接被前端使用。 资源示例

　　类库

　　除了框架以外还有不少类库，好比jquery，underscore，linq.js(linq to javascript)，jscex(wind)反正后端有啥如今前端也有啥，尽情发挥想象吧。用好这些框架能够大大改善生产力的，脚本能作的事情真的比想象的要多的多。我是作后端的前端知道的很少在这里列出的可能只是九牛一毛。

　　依赖

　　可使用Requirejs、Commonjs之类的组件来管理脚本之间的依赖，好处不少的，咱们的模块只须要写清楚须要依赖什么，Requirejs天然会帮咱们按照必定的次序加载进来，这样咱们既不用担忧顺序问题也不用担忧组件的版本号问题。基于Requirejs它具备丰富的配置，即便是咱们进行了静态资源合并也彻底能处理，只要经过配置把组件配置到相同的服务端生成的一个路径上便可，不过之前在作的时候发现它会自动加上.js 扩展名，不过彻底能够经过改Requirejs源代码解决。在架构上个人观点是既然使用开源的东西，遇到问题了就不要去怕改源代码。咱们必定不能停留在框架的使用者，定制框架甚至向做者贡献本身的代码没有这么难。 设计层面：

　　职责分离的理念

　　虽然咱们都知道CSS样式、JS行为以及HTML结构。我的以为只有HTML是必须的，也就是说若是一个页面没有样式没有脚本的话它应该是一个清晰的页面，能够大体表现出页面须要表现的内容，只不过样子比较难看，而且也是交互的。若是说不少功能是ajax实现的话那么就把交互工做转到服务端实现服务端的渲染。多了样式只是布局上样子上更好看，多了脚本只是交互性上更友好，不须要刷新页面，可是少了也不表明这个网站就是废物了，如今有不少理念其实目的是同样的。若是达不到这个境界至少咱们要很明确的让css、js和html履行本身的职责，不要把过多的事情赋予不相关的组件。好比尽可能不要在html中包含操做性的脚本代码，而是应该直接在脚本中选择dom元素进行操做，尽可能不要在脚本中包含大段的html代码而是应该从模板读取而后把数据填充进去，也尽可能不要在html代码中包含大量内嵌的样式而是应该经过选择器选择进行样式赋值。 资源示例

　　分层和目录结构

　　对于一个比较复杂的大型的项目，合理规划目录结构也是很重要的，你可能会说脚本和样式分两个目录就能够了，可是若是一个复杂的项目有几百个脚本都列在一个文件夹下吗?后端有分层的概念其实前端彻底也能够有分层的概念，有表现层、业务逻辑层和模型层，而后是下面的数据访问ajax层，固然还会有常量的文件，我反问以为前端的分层能够超大型项目的ios或android程序来靠。好比以前我作的一个ios程序的示例,我的以为这样的分层就比较一目了然的。

　　合并和拆分的平衡

　　不少时候架构上的东西就是一种权衡，若是有固定的标准的话也就不须要架构师了，咱们只须要按照固定的标准去作就好了。好比，一个页面上使用了10个脚本文件，5个样式文件，按道理说合并成两个文件能够达到最小的请求数，但这样必定是好的吗?这个10个脚本和5个样式文件中有不少或许是其它页面也须要公用的，若是仅仅简单的合并在一块儿反而可能增长用户的下载流量，所以怎么规划通用的东西合成一个文件，框架的文件单独，而每个页面都有本身独特的脚本和样式，也是一种学问。 性能层面：

　　性能检测

　　诸如YSlow和PageSpeed等工具能够分析出前端的性能问题，在这里就不展开讨论了。对于前端来讲因为涉及到用户的客户端环境和网络环境因此状况不是这么单纯，可是咱们能够作到的就是在咱们的可控范围以内尽可能减小用户域名解析数量，减小用户下载的数据量，增长并发等等。其实说白了，咱们就是清理管道使得管道更大，或者增长更多的管道，或者就是尽可能让管道以内的水少一点了，这样就能够更顺畅。 资源示例

　　性能分析

　　如今有一些工具能够对Javascript的性能甚至是DOM解析的状况进行细致的分析，好比dynaTrace AJAX Edition，经过这样的工具咱们能够分析咱们的脚本代码以及页面布局是否合理，从开发的角度来全面了解和优化咱们的前端代码。客户端的资源虽然不像服务端的资源这么重要，可是为了给用户的机制体验最好仍是对客户端的性能消耗有所优化。