微软项目 -->Atlas

    技术2022-05-12  15

    微软致力于简化Ajax风格Web应用的开发,并提供丰富的、可交互的和个性化的用户体验。开发者可以对客户端脚本不甚了解;但他们可以很容易地开发和调试这种应用程序。

     

    出于这一目的,微软启动了一个新的项目,研发代号“Atlas”。Atlas为开发这带来了如下特性:1.Atlas客户端脚本框架 2.Atlas的ASP.NET服务器控件 3.ASP.NET Web Services集成 4.Atlas的ASP.NET构建块 5.客户端构建块服务

    Atlas是编写丰富的、可交互的和个性化的Web浏览器应用程序的最好方式。而Avalon是微软的下一代表现层模型,可以在Windows平台上提供最丰富的用户体验。Avalon将使用最新的媒体集成功能和硬件加速设备,提供卓越的视觉体验。Avalon将带来超越浏览器的体验。

      当然,当你构建Avalon应用程序的时候,你依然可以重用ASP.NET和Atlas中的编程模型。例如,Avalon客户端上依然可以使用ASP.NET构建块服务和客户端构建块服务。这种模型可以使你平滑地过渡到下一代应用程序上。

     

    Atlas 优点:

     

    仁者见仁,智者见智。在这种问题上每个优秀的技术人员应该总是有自己独特的见解。能得到一个能“服众”的结论固然好,但是支持百家争鸣更为重要。我始终认为Atlas的最大长处不在于其Ajax特性,不在于其提供了复杂JS才能实现的多样化功能。在我看来,Atlas是很了不起的,而它的了不起体现在三个地方:

      1. Declarative Syntax:   应该有不少人有过在HTML Element中嵌入浏览器无法识别的属性,而在某个地方通过自己编写的Javascript方法读出并加以一些功能。其实我在数年前总觉得这样的方法是tricky solution。我不喜欢tricky的方法,特别是无条理性的tricky solution。这样的方法的确可以work,但是可读性一般比较差。在大多数时刻,我始终把代码的可维护性放在第一位。后来由于在项目中需要开发一个Rich Client,给用户以大量的操作自由度(描述不当,不过估计无法用三句两句话说清了),于是不得不使用了这个方法。在进行了大量尝试后,发现如果合理使用,这的确是一个非常灵活有效,并且易于维护的方法。ASP.NET强大的客户端Element模型又可以说对这种方法合作的几乎天衣无缝。   Atlas的Declarative Scripts可以说将上面提到的这个方法进行了极大的升华。将一个从一开始似乎十分Tricky的方法变成了另一种开发方式,将程序设计和XML结合在了一起。事实上,这给了许多项目设计一个参考。将客户端代码的结构化也大大地提高了可维护性。   原来,代码还可以这么写。     2. Extendable Behavior, Extender, etc.   它们所作的贡献是提供了良好的设计。能让程序员轻松地写出符合良好设计的代码。   一个良好设计的代码,其中一个非常基础的特点就是“high cohesion”,也就是“高内聚”。高内聚的组件与外界的依赖很少,这样大大方便了开发,调试,测试,发布和部署。   就拿开发一个Extender来说,需要的就是写一个Class Library,并编译成一个程序集。使用时只需简单的引入,并像使用普通控件一般即可。在开发时需要的也仅仅是Atlas的基础结构,少得不能再少的一个程序集。   还是一个典范,还是一个示例。     3. Powerful Foundational Framework   这里不提Atlas提供了一个完全面向对象的编成框架,提供了一个Compat层来兼容多个浏览器等。现在来思考一个问题:如何写出高性能的Web应用程序?   或者换个角度想一下,一个网站的性能是从什么方面体现出来的?这不光是要服务器端的努力,特别是现在客户端越来越Rich,客户端的Load也越来越多。优化PLT(Page Load Time)也是一个越来越重要的议题。这需要对于浏览器,HTML以及HTTP标准有相当完整的认识。通过分析Page Load来优化一个页面能够达到非常了得的效果,经过PLT优化的网页往往能将一张页面的打开时间缩短3-5秒甚至更多,并且往往也能减少服务器端的运算以及流量。   Atlas的基础代码框架的每一步都是尽量地符合优化PLT的Best Practice。所以使用Declarative Script和Atlas框架所提供的JS类往往效率会比较高。打个比方,浏览器对于相同域名只会并行地使用两个端口进行加载,因此将不同资源从不同域名加载是优化PLT的一个常用方式。但是由于可能JS中任何部分的代码都可能会改变的页面的DOM或者Render出不同的内容(例如使用document.write),因此浏览器在下载JS文件时是会Block住其他任何的资源加载,无论其是否在同一个域名中。加上现在JS文件越写越大,数量越来越多,因此浏览器的加载能力就被削弱了。在Atlas中,Binding机制能比较好地处理JS加载问题,以优化页面的PLT以及Perceived Performance。       Atlas的缺点?     其实我有时候总是会想,Atlas代码是不是写的太庞大了,使用起来方便吗?比如其OO特性,使用起来似乎不是很方便,代码量和代码体积颇高,而且对于没有接触过Atlas的人不是很容易看懂。外界不少提供面向对象机制的JS框架似乎就精炼许多。我也因为某些需要为JS写了一套面向对象机制的扩展,很简单,使用方便,OO机制使用方式也是尽可能地向Java代码靠拢。继承,虚函数等必须的功能也一个不缺。   不得不说,这个似乎是Atlas的一个瑕疵。但是瑕不掩瑜,Atlas依旧是一套优秀的JS框架。它实现的Ajax,却又远远超越了Ajax本身。冲着Ajax or .NET来接触Atlas的程序员往往总是能从它身上得到惊喜。

    最新回复(0)