面向.NET开发人员的Ajax 技术平台策略(3)

唐僧爱灭绝师太

唐僧爱灭绝师太

2016-02-19 18:48

下面图老师小编要向大家介绍下面向.NET开发人员的Ajax 技术平台策略(3),看起来复杂实则是简单的,掌握好技巧就OK,喜欢就赶紧收藏起来吧!

  之前我提到过"似Ajax" 的架构,现在我要说的Ajax框架也就是指专门针对这种Ajax架构而提供的框架。目前,我还没有听说过特别好的这个领域的流行框架。但我知道我的身边,.NET领域,J2EE领域或PHP平台上都有这样的框架和应用,我认为,正是因为有很多这样应用,所以Ajax才会像某个模式一样,被撰有一个专门的名词。不过我感觉Ajax 渐渐变成了Ajax feature的代名词,变成了XMLHTTP的代名词,成了异步通讯,不刷新页面的技术表示法。直到我看过Ajax in Action这本书,我才把Ajax和系统的架构、设计模式,分布式对象的序列化和我之前的项目和经历联系在一切。

  我修改了一些Jesse的图,来说明我认为的基于Ajax的架构是什么样的。

  这也就是我上面说的似Ajax架构,首先它是一个Web应用;它的表现层用DHTML+CSS + HTC控件+ Javascript ,服务器端用.NET或任何的服务器端技术,中间以XML方式序列化和反序列化进行传递数据。

  简单的说,客户端需要将请求的数据封装成一个XML数据通过HTTP传递给服务器端,服务器端处理这个请求,并将结果也以XML的形式返回到客户端,客户端再处理这些请求,然后使用HTML+CSS进行展示。其实如果不是Web客户端(浏览器)的问题,这是最简单的架构,但关键问题在于上面我们说的Javascript端的对象封装成一个XML,以及到服务端解析XML变成服务器端对象,然后再将结果封装成XML,传回给客户端(Javascript),客户端也解析XML数据,然后变成Javascript 中的对象的这个序列化和反序列化的问题。另外一个问题就是表现层的展现问题,怎么展现,用什么控件?

  所以,一个Ajax架构的Web应用程序,必须解决下面的问题:

  1. 双向两路的序列化问题

  2. 表现层展现的问题

  3. 传输时客户端和服务器端的数据安全问题

  4. 性能问题

  5. 国际化支持

  最好玩的双向两路的序列化问题,最早接触的是JSON ,它的问题在于扩展性,数据类型的支持和性能,但是平台无关性比较好,什么浏览器都可以,因为它不需要用msxml2.DOMDocumen分析XML,本质上就是用字符串描述对象;之后多平台的应用的迁移经历中(比如CORBAR,J2EE的后台应用),开始接触到XML-RPC ,ICE,Hessian,Web Services等等。其中XML-RPC有Javascript 的支持库,Web Services也有Javascript的支持库,也就是你可以使用Javascript访问或者获得XML-RPC/Web Services的对象,但是如果你将其作为一个主要的通讯协议,那么就会遇到另外一些问题,比如性能、国际化的问题,又会困扰你,XML-RPC和Web Services的一个主要问题都是性能,因为他们传输的XML大小都太大了,但显然用这些实现一个Ajax的特性,那是完全没有问题了。

  比如,Atlas目前不也是使用一个Javascript库调用Web Services吗?,所以,你也可以这么做,同样你也可以用XML-RPC.NET 很快就可以实现一个Service,然后使用Scotandrew的XML-RPC javascript 库就可以在Javascript中发一个XML-RPC 消息请求这个服务,然后异步的获得这个结果,然后展现它。所以从技术的实现上讲,Ajax的特性非常容易实现,但从架构上来看。你需要思考更多的因素。当然直到最后,我们才发现,在项目中,最完美的方案是你自己写一个双向两路的序列化引擎供你的Javascript客户端使用。

  这就说到了第二个问题,界面表现的问题,这个问题也是一个大的问题。这个问题一直会永远存在,Ajax之前没有人会太注意这些,但今天不同了,我想未来还会有很大的一个飞跃, Yahoo! 不是最近也开源了他的Yahoo! Web UI库,Atlas 也表示要提供更多的前端UI控件。无论如何,这个问题是,你的团队或组织是否有一套经过项目或客户检验的前端Javascript的库。无论是自己用Javascript写的也好,是自己写的一套HTC的控件库也好,总之这些是Ajax 架构中非常重要的一环。

  Atlas 带来了另外一个思考问题,就是服务器端控件可能可以通过某种方式和Javascript的控件很好的集成在一起,以前我们用HTC解决了重用、性能、Behaviors、甚至模板功能。但是新的特性还是有比如数据的绑定、缓存和校验、甚至是数据编码和压缩、加密和解密,Javascript UI前端还是有许多可以做的,而且如何无缝的集成两者,这个有非常大的意义。

  接着安全、性能、国际化等等,架构中的问题需要你依次考虑和解决,如果这么看Ajax,我认为,目前的Ajax框架还有很长很长一段路要走,同样真正完美支持Ajax架构的还需要继续努力。这些也是我在这篇专栏文章中的观点。

  把这些合在一起,那么Ajax架构的开发包或框架,就应该是包含了上述几个问题(两路双向的序列化、Javascript UI 表现库、安全、国际化和性能等等)解决方案的一个平台实现。

  同样也许你会说,不就是Ajax吗? 我干嘛要搞这么复杂,一定要搞到架构这个层面。

  我认为,

  第一,从架构的层面看Ajax,然后再应用相关的技术,比你直接使用某个Ajax框架然后再理解Ajax,你会从这个过程中收获更多。

  第二,对于一个开发团队/组织来说,真正Ajax架构的产品,可以带来效益和具体的生产力。比如,我身边就有拥有这样的优势的团队,他们拥有一套统一的由Javascript+HTML+CSS+HTC的前端表现层,而后台的业务系统有两个平台,一个.NET平台和J2EE平台;同样我身边的也有这样的团队,他们拥有一套统一的由Javascript+DHTML+CSS+HTC+VML+ASP.NET的前端表现层,但他们的后台业务层分别来自.NET平台、J2EE平台和Unix平台,我不能说Ajax架构的应用似乎就是统一Web 表现层。因为从今天看到他们的明天,也许会是, 一个ASP.NET V2+Atlas 的统一表现层,一个统一CAB+Smart Client 的统一表现层,也可以是一个WPF 3D的统一表现层,也可以是一个Xgl 桌面的统一层......

(本文来源于图老师网站,更多请访问http://m.tulaoshi.com/webkaifa/)

  第三,从这架构的层面上,你也能够非常容易理解SOA或ESB概念,和SOA相比,Ajax架构的区别在于,Ajax有足够的松散耦合,但它依然以应用的数据为中心,更多的是一个面向Messages的架构,而且对于流行的WS-*协议的支持非常有限。

  但是假如,今天你或你的团队已经有了一个Ajax 架构的应用,那么你是不是应该要小心选择现有的Ajax框架,因为这些Ajax的特性,相对于目前的架构来说,是多么小,但又可能会产生很大危害的一个因素。也许这样的团队并不多,也许也很多,但是只有我们从更高更深的层次来思考,那么我们就能做出正确的选择,并且从新的Ajax技术和研究中获得好处。

  结论

  当我们回到文章的起点,我希望这样能够说明的我观点,即Ajax-NET的框架或实现分为两类,一类是基于Ajax应用程序架构的,一类是基于Ajax特性的,目前几乎大部分的Ajax-NET的框架或实现都是基于Ajax特性,以Add-in 方式提供的代码或框架。

  Ajax-NET的实现/框架选取上的建议:

  ASP.NET控件形式已经成为连接服务器和客户端Ajax通信的主要形式和选择。

  客户端调用服务器端页面中的方法是Ajax的重要手段,使得客户端可以更加灵活的获得服务器端的数据。

  MagicAjax.NET,Anthem.NET用了"Hook ASP.NET"和Add-In的技术手段,使用上受到的影响比较多,这两个框架中,最简单的应用,第一选择MagicAjax.NET,但总是优先使用Anthem.NET。

  如果是自己写的服务器端控件,那么应该先掌握Anthem.NET的技术,然后使自己的控件拥有Ajax的特性。

  MagicAjax.NET, Anthem.NET和wwHoverPanel 对于国际化的支持都有待加强。

  在Atlas没有正式发布之前,在ASP.NET的应用中优先在自己的项目中使用类似wwHoverPanel的技术,即尽可能的使用客户端回调功能,在特别需要的地方使用其方法调用的功能,充分发挥Ajax的特性,而不要因为Ajax而特意选择某个Ajax的框架。

  Atlas的强项在于服务器端和客户端控件特性的集成、客户端的数据绑定、校验、内置的多个客户端Ajax 特性UI或组件,与ASP.NET的Profile, Membership ,Role 服务的集成,与Web Services和WCF 服务的集成,以及良好的国际化/开发工具支持的。因为它是一个完整的解决方案,所以最大的弱点是不能很容易地被老的Ajax架构的应用使用。另外该产品目前还在不断开发中,距离部署到生产环境中的要求还有差距。

  轻量级的双向序列化可以考虑JSON格式,安全问题可以在传递的对象中增加字段,然后在服务器端进行校验。

  对于原来已经有一套序列化框架的组织来说,其主要的目标是尽快将这个框架迁移/升级到ASP.NET V2,而不是优先考虑实现某个Ajax的特性。

  Ajax 要求有足够的力量关注前端的UI展现或开发,所以对Ajax实现/框架的选择,最先要考察其客户端的实现以及提供的Web UI。

  看完这篇文章,我希望,今后我们再谈起Ajax的时候,作为技术人员,我不用谈论什么Web 2.0,我一样可以清楚的表达Ajax的概念
如果你是一个架构师,Ajax 不再是什么异步的XMLHTTP调用,不再是不刷新页面,它可以帮忙你Review应用程序的架构。

  对于你的团队或老板来说,Ajax可以是你统一界面表现层的一个策略,同样也可能让你有了一个创建一套部门或公司级能够重用的UI类库的机会。

  同样对于Javascript的开发人员来说,Ajax让你们还需要了解一些业务,并证明前台的Web开发人员一样很昂贵,后台开发也可以是技术含量不高的。

  对于SOA的爱好者来说,Ajax架构让你能够站在面向消息的架构和系统上来看面向服务;一般我们说,对内你首先要有一套面向消息的架构,然后对外你就很容易延伸成一个面向服务面向Internet的分布式架构。

  最后,不要讨论Ajax的消亡,因为Ajax对于程序员来说,是一种力量均衡的策略,在Ajax中,Web前端的开发人员被重新重视,成为一支重要的力量。

(本文来源于图老师网站,更多请访问http://m.tulaoshi.com/webkaifa/)

  后记

  写这些文字的某几个段落,让我有些痛苦,因为我本来没想些这么多。所以你不要太在意我对各个框架的评价和描述,这些都是技术的层面的东西,其实我写这篇文字,主要是想突出Ajax的架构观,以及设计模式和Web应用架构重构的考虑,续而你也能够用类似横切面的角度,用Ajax来看你目前的应用和架构,从而更深的了解分布式对象的序列化、性能、安全以及Ajax 和ASP.NET服务器端控件的融合。最后欢迎大家斧正。

展开更多 50%)
分享

猜你喜欢

面向.NET开发人员的Ajax 技术平台策略(3)

Web开发
面向.NET开发人员的Ajax 技术平台策略(3)

面向.NET开发人员的Ajax 技术平台策略

Web开发
面向.NET开发人员的Ajax 技术平台策略

s8lol主宰符文怎么配

英雄联盟 网络游戏
s8lol主宰符文怎么配

面向.NET开发人员的Ajax 技术平台策略(1)

Web开发
面向.NET开发人员的Ajax 技术平台策略(1)

面向.NET开发人员的Ajax 技术平台策略(2)

Web开发
面向.NET开发人员的Ajax 技术平台策略(2)

lol偷钱流符文搭配推荐

英雄联盟 网络游戏
lol偷钱流符文搭配推荐

一个开发人员眼中的JSP技术(上)

Web开发
一个开发人员眼中的JSP技术(上)

一个开发人员眼中的JSP技术(下)

Web开发
一个开发人员眼中的JSP技术(下)

lolAD刺客新符文搭配推荐

英雄联盟
lolAD刺客新符文搭配推荐

AJAX技术开发Back按钮问题的应用程序

AJAX技术开发Back按钮问题的应用程序

Oracle数据库视图管理经验技巧

Oracle数据库视图管理经验技巧
下拉加载更多内容 ↓