应用程序框架实战二十八:前端框架决择

　　对于BS管理系统，我很长一段时间都工做在Asp.Net Web Form上，Web Form的主要优点是可使用服务器端控件，以相似CS的开发模式进行工做，经过拖拽控件和定义事件处理函数，极大的简化了BS的开发。服务器端控件会在渲染阶段把自身输出为Html标签，对咱们彻底透明，当须要设置相关属性时，只须要在属性面板上操做便可。

　　Web Form在诞生之时，Ajax还未流行，因此页面的提交是彻底刷新方式。为了记住控件的状态，Web Form引入了ViewState和回发机制。对于一些复杂的界面，可能建立大量的服务端控件，查看ViewState序列化生成的hidden，有时候达到数百K。回发机制也让人郁闷，手工编写的Js与回发机制不能很好的配合，常常发现代码的执行时机不对。Web Form服务端控件生成的Html也至关杂乱，基本是面向机器的。

　　固然这些问题不少时候是本身的使用方式不对，不能全赖到Web Form上，但你们但愿.Net可以提供更好的解决方案。

　　Ajax逐渐流行，对BS的要求大幅提高，好比局部刷新，干净整洁的Html等。一些 RIA框架发展起来，好比Ext、EasyUi、Dwz等。

　　微软也推出了轻量级的Mvc框架，我是在Mvc 3 发布时才开始使用的，主要是被Razor视图引擎吸引过来。为了提高用户体验，还选择了一款RIA框架，当时选择了Dwz，主要是它开源免费，而其它框架要么闭源，要么收费，或者太复杂了，学习成本高。

　　在使用了几年Dwz以后，最近决定更换一个前端框架，下面谈谈使用Dwz的一些状况。

　　Dwz做为一款国产免费的开源框架是值得支持的，官网http://www.j-ui.com。经过Dwz，我学习到大量Js和Css的相关知识，在此表示感谢。

　　Dwz基于JQuery，设计以Html扩展为主，对SPA (single page applications, 单页应用程序)有很好的支持，API命名规范，代码质量较高。

　　使用中碰到的问题也很多，首先是缺少专业的文档，官方只提供了一个很简单的使用手册，每当碰到问题，我老是进入dwz源码断点调试，不过这样更能深刻学习内部机制，彷佛也不算严重的缺点。

　　从我开始使用Dwz，好像就没见更新过。

　　Dwz有些组件不够完善，好比弹出模态窗口，只支持弹出一层，若是在弹出的模态窗口上继续弹出模态窗就不支持了，而这属于经常使用功能，对于这些小功能，我本身修改，咬咬牙也仍是能够搞出来。

　　对于一些重量级的组件，好比表格、树等，Dwz提供的比较弱，我通常都引入第三方插件，好比ZTree。

　　还有一个头痛的问题是布局，Dwz没有提供border或fit这样易用的布局方式，除了面板和Tabs等常规布局组件外，只有一个神秘的layoutH属性，它的值是一个数字，表示工具栏的高度，对于一个复杂点的布局，我常常东调西试以找出这个正确的数字。固然这也只能怪我水平有限，掌握不够好，因此引入一个更强大的前端框架就迫在眉睫。

　　对于大名鼎鼎的Ext，我已经关注它很长时间，不过一直没敢使用它，有几个缘由。使用纯Js开发界面，有点违反通常程序员的习惯，大部分程序员仍是喜欢用Html布局。另外一个缘由是面向对象的Js要求比较高，API丰富而庞大，学习成本高。固然最重要的一个缘由是，对于管理后台这样的系统，大量手写Js开发效率低，且Js是弱类型语言，代码提示很弱，且没有编译时检查，容易出错，健壮性差。因此哪怕要使用Ext，我也会用C#来包装一次，这个工做已经有人作了，这就是Ext.Net。十分遗憾的是，Ext.Net不是开源的，并且还收费，它甚至把js等资源内嵌到dll中，另外还不支持DataAnnotations验证，这让我打消了使用它的念头。

　　Ext也是要收费的，但有一个版本2.0.2能够无偿使用，个人想法是，若是作小项目，就用高版本，偷偷的用估计也没人知道，若是须要公开使用，就切换到2.0.2这个版本。经过C#建立一个抽象机制，不只能够简化开发，并且能够方便切换版本。我在尝试了一段时间后，发现封装的工做量很大，因此暂停了，待之后确实须要的时候再继续。

　　目光转到EasyUi，EasyUi传说也是国人开发的，不过其官网倒是纯英文。对于EasyUi，我几年前也曾了解过，当时认为没有源码，万一出现bug不是束手就擒吗。虽然如此，我却发现它愈来愈流行了，博客园搞框架的十有八九都是用的EasyUi，周边也有不少公司在使用，甚至在招聘要求上，我也看到过要求有EasyUi的经验。这说明EasyUi的稳定性仍是有保证的，你们用都没问题，难道个人运气就那么背。

　　除了跟风之外，我选择EasyUi还有几个重要缘由，首先是功能比较强大，重要的复杂组件和布局组件都提供了，虽然没有Ext那么完善，但也基本够用。其次是学习成本低，EasyUi也是基于jQuery，并且支持Html扩展。最后是官方文档比较齐全。

　　能够看到，EasyUi的功能、文档、易用性等介于Dwz与Ext之间。

　　还有一些朋友给我强力推荐Bootstrap，不过我感受它有点轻量，管理系统须要更重口味的框架，开发相似会员后台的时候再考虑采用Bootstrap。

　　我学习EasyUi还不到一个月，不少东西仍处于摸索中，EasyUi虽然比较强大，但仍是发现很多问题。

　　首先是它的方法调用方式让人很郁闷。好比我如今要关闭一个窗口，须要这样调用$('#xxx').dialog('close')，为何不能这样调用$('#xxx'). close ()。还好我主要使用Html扩展方式，手工编写Js仅用来处理回调，这个问题能够忍忍。

　　其次发现很多小bug，好比多行文本框没法回车换行，时间控件在某些时候点击时报对象为null的错误等等，我使用的是IE 11，估计做者尚未对IE 11进行全面测试，但愿能及时更新。

　　EasyUi虽然是一个比较完善的前端框架，但并不意味着不须要花任何力气，你就能够开发出健壮的应用。下面讨论两个重要的设计决策。

SPA仍是IFrame

　　SPA，全称Single Page Applications, 即单页应用程序。它的设计理念是仅在主框架界面使用一个完整的Html页面，其它全部内容页面都是Html片段，没有html、head、body这些标签，主框架界面经过ajax的方式加载内容页面。

　　SPA是正宗的Ajax应用模式，而且逐步成为Ajax应用的趋势。它的优势显而易见，全部东西都在同一个页面，查找任何元素，直接用jQuery选择器就好了。

　　任何事物都有两面性，SPA也有不少缺点，最严重是命名冲突和兼容性。

　　对于同一个Html页面，若是两个元素的id出现重复，当你用css选择器进行格式化，或用jQuery选择器对其操做时，就会发生意想不到的状况。你会发现，操做某个内容页面时，竟然影响到另一个不相干的内容页。

　　jQuery解决这种命名冲突，是经过传入一个额外的上下文对象，好比$(“#xx”,context)。Context表明某个内容页，这样就能够仅查找该内容页的id，从而消除了命名冲突。

　　对于SPA，Dwz提供了自然的支持，它封装了CRUD相关的全部操做，并提供了一个当前上下文context来保存当前操做的内容页或弹出窗口。

　　虽然Dwz提供了SPA支持，但我在使用中，依然发现偶尔出现各内容页互相影响的状况，为了防止命名冲突，我将id命名得很复杂，以减小冲突。

　　再看EasyUi，对于CRUD操做，只在官网找到一个很简陋的Demo。仔细研究了Tabs等组件后，感受EasyUi默认支持的是SPA模式，由于这些组件都没有对IFrame进行支持。EasyUi既然支持的是SPA模式，但却没有作进一步的封装，能够判定，以SPA模式使用EasyUi，命名冲突是比较严重的。

　　还有一个头痛的问题是兼容性，因为全部内容页面在同一个Html中，若是某些页面须要引用一个第三方插件，而这个插件不是基于jQuery的，或者jQuery版本不一样，引入这些插件可能失败。

　　基于以往的经验，我决定不在管理系统这种复杂的应用中使用SPA，而是使用IFrame的方式加载内容页。

　　因为EasyUi没有对IFrame提供支持，当我向主界面的Tabs引入IFrame后，引起了一大堆连锁问题，我花了大把时间终于把这些问题解决了，后面将用专门的文章来介绍碰到的障碍。

封装有无必要

　　大部分使用Mvc的朋友，都是从Web Form转过来的。所谓一遭被蛇咬，十年怕井绳，因为在Web Form上吃过过分封装的苦头，来到轻量级的Mvc世界，他们惧怕服务器端的任何东西，只敢使用原生的html和js了。

　　Mvc提供了一套Html表单控件的封装，好比文本框，@Html.TextBox( "id" )，它等价于<input type="text" name="id"/>。从这个简单的例子，好像使用服务器端语法优点并不明显。但值得注意的是，服务器端语法可以将DataAnnotations验证自动转化为jQuery验证，这一点仍是比较强大的。

　　对于简单的html标签，你是否使用mvc的服务端语法不是特别重要，但对于像Dwz或EasyUi这种Html扩展为主的前端框架就很是必要了。

　　EasyUi将每一个组件的属性都扩展到了Html标签上，对于Html标签，你还能期望代码提示吗？没有代码提示，就意味着你得随时打开EasyUi的官网，以复制相关的属性。固然你不少时候会本身手工输入，你必须把这些API记得很是精确，若是多一个或少一个字符，你就会获得错误的结果。若是你没有遵循敏捷开发的小步前进，而是把整个页面输入完成才开始运行，在密密麻麻的Html标签中找出输入错误的属性也不是一件容易的事。

　　若是把EasyUi的属性用C#封装起来，由C#来输出Html标签，你就能够彻底再也不操心API的问题，全部的API只需在代码提示中上下移动便可。能够看到，Web Form的不少思想实际上是很是好的，好比用服务端代码输出客户端代码，你应该去其糟粕，取其精华。

　　对前端框架的封装，真正强大的地方来自Lambda表达式。

　　从Lambda表达式中，你能够获取到一些元数据信息，好比name、value、验证信息，一个简单的操做@Html.EasyUi().TextBox( t => t.Name )，可能设置了10几个属性，而且全部的属性均来自服务器端，这样维护也更加方便了，你不用来回修改客户端代码。

　　Lambda表达式还能够获取到属性的类型，这有什么用呢？当你写上一句@Html.EasyUi().TextBox( t => t.XXX )，若是XXX是整型，文本框就自动转成EasyUi的数字文本框，只能输入数字，若是它是一个日期，文本框就显示成一个日期控件。再好比@Html.EasyUi().Combox( t => t.XXX )，当它是布尔类型，就显示一个是、否的下拉列表，若是它是一个枚举就自动绑定一个枚举值的下拉列表，这是否是比你手工输入要强些呢。

结语

　　本文简要介绍了我对几个前端框架的认识，也说明了封装的必要性。

　　因为我也是EasyUi初学者，我提供的Demo并非一个能够直接使用的框架，不过做为学习范例，你能够把它做为你的应用程序框架的起点。

　　我后续文章会逐步介绍Demo中各构造块的封装和使用要点，全部代码以我最新发放的Demo为准。

　　为了避免冲淡本系列主题，我会专门为EasyUi框架的封装建立一个系列。

　　对于EasyUi的封装，我并没打算封装它的所有内容，毕竟我不是靠这个吃饭的，我仅在开发时碰到需求才会进行扩展，个人Demo会随着个人开发逐步加强，我会按期发放最新源码。

　　Demo已更新，须要的老规矩，点推荐，留Email，本次截止2015年1月28日15点。

　　另外你们短期没收到源码不要着急，只要在规定时间内均可以拿到。

 

　　.Net应用程序框架交流QQ群: 386092459，欢迎有兴趣的朋友加入讨论。

　　谢谢你们的持续关注，个人博客地址：http://www.cnblogs.com/xiadao521/