Spiga

有感Atlas - 优点、缺点、学习

2006-09-12 16:52 by Jeffrey Zhao, 3349 visits, 网摘, 编辑
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的程序员往往总是能从它身上得到惊喜。
 
 

学习Atlas……
 
  我经常在我身边的开发人员中推荐.NET,虽然无偿,但是冲得就是对这一技术的喜爱。我是技术人员。当然对于Atlas也向别人进行过介绍,也看到不少人学习Atlas的情况。

  似乎Atlas进入了.NET相同的情况,大家纷纷在使用,感觉很爽,而去了解它是如何做的人却很少。知道在什么情况下如何使用的人也很少。而且能够灵活使用的人,往往也对其机理有了相当认识。可能的确只有从一个特定的层次以及角度去看它,才能对它有更好的掌握能力。“使用论”和“深入论”的争锋似乎依旧存在。忽然想起Jeffrey Richter说过他的CLR via C#市场反响不好,现在越来越少的人希望从CLR层面去了解.NET Framework……

  其实我也是“使用论”的支持者,但是我仅仅支持良好的使用方式。这都不是一朝一夕能够炼成,也不是仅仅靠了解一门技术就能做到的。要成为一个优秀的技术人员,所需的技术覆盖之广,其实远超过普通技术人员的想象。
Add your comment

30 条回复

  1. #1楼 aspnetx      2006-09-12 17:01
    it just makes everything easy...
    easy to gain,easy to learn,easy to use
      回复  引用  查看    
  2. #2楼[楼主] Jeffrey Zhao      2006-09-12 17:07
    @aspnetx
    make everything easy很好,但是容易让人不去了解它,容易让人随意地使用……
      回复  引用  查看    
  3. #3楼 aspnetx      2006-09-12 17:19
    @Jeffrey Zhao
    but how about one wants it to be extended,
    that will be make him get lots of things to learn.

    use it as one's mind is the way that lots of framework done,and easy is not mean too simple,I think.
      回复  引用  查看    
  4. #4楼 Dflying Chen      2006-09-12 17:22
    Atlas最大的缺点就是太慢了!!慢的不可忍受,慢的不实用。
      回复  引用  查看    
  5. #5楼 aspnetx      2006-09-12 17:26
    @Dflying Chen

    Welcome Back!

    We are waiting for your new post!
      回复  引用  查看    
  6. #6楼[楼主] Jeffrey Zhao      2006-09-12 17:47
    @aspnetx
    需要make everything easily和make every properly中找到一个平衡。
      回复  引用  查看    
  7. #7楼[楼主] Jeffrey Zhao      2006-09-12 17:48
    @Dflying Chen
    所以需要尽可能地去优化JS Code,这又要考察开发人员的水平了。
      回复  引用  查看    
  8. #8楼 Dflying Chen      2006-09-12 19:12
    @Jeffrey Zhao
    呵呵,远没有我们想象的那么容易,Atlas先天不足,在我的文章:http://dflying.cnblogs.com/archive/2006/05/01/390401.html 中headchen朋友有这样一条评论,绝对入木三分,这才是真正高手的看法:
    (以下引用headchen朋友的评论)

    1. javascript试基于原型prototype的继承机制,通过构造函数和原型对象来模拟类。这一点在Atlas中当然不会发生改变。只不过他在暗地里全都处理了,处理得方法是:派生类拷贝了基类原型对象得所有方法到自己得原型对象中。这样当一个派生类继承于一个基类时,自动继承类通过原型对象实现得实例方法(当然派生类的原型对象中若存在同名方法,则不拷贝)。

    2. Atlas通过registerBaseMethod来声明得虚方法仅仅时构造函数得内部方法(有一些文档中称为privilege方法,意思时能够访问构造函数得局部变量,Atlas正是通过这个来模拟私有变量的)。而Atlas中大量的get_ set_正是此类方法。

    3.在javascript中实现一个类的实例方法有两种途径:1 把方法定义在原型对象中,这个在使用时自动通过访问原型链来访问实例的方法。这种方式的好处是节省内存,效率比较高(这里说的效率是实例化对象时的效率),因为多个实例的方法都存在一个原型对象中。2 定义为原型对象的内部方法(上面已经说过来),这种方式,在初试化实例对象时,实际上是给每个对象实例都定义了一个相应的方法。所以初试化实例对象时需要更多的内存和时间。但这种实现方式有他存在的必要性,那就是利用函数的closure特性来实现特有的需求,比如:生成事件委托,回调函数,实现局部变量等等。但如果对象实例很多时,存在很大的效率问题,所以把他称为privilege方法也时有道理的,那就是他的存在的理由就是为来利用closure。

    微软在Atlas种大量使用privilege方式来实现实例方法,而有意无意的淡化来javascript固有的prototype的实现方法,从语法上来看更接近C#的语法,另外Atlas种存在大量的get_ set_ 类方法也只能通过这种方式来实现,我们也看到绝大多数类实例的方法,即使不是必须,也大多采用类这种实现方式,而不是prototype的方式。对于这种动向,本人时持有反对意见的。很明显的看出:Atlas有.net情结。想在javascript环境实现一个稳固严密的架构,但确牺牲了 javascript原有的灵活性,并且牺牲了大量的内存和效率。

    所以我们可以利用Atlas提供的一些扩展,比如对于String Array Function等的扩展,特别时命名控件,事件委托等等。但不必完全拘役于它或者完全模仿他。

    Atlas对Function,Array,String的扩展是通过prototype来扩展的,这也是javascript中的唯一的选择,也是 Atlas的基础性的建设。我说的Atlas内部函数的倾向是指架构中类(class)以及继承等的实现。可以看出,在Atlas中除了对 Function,Array,String,Date的扩展和对Event的实现外,其他类的实现均是通过内部函数的方式,而不是prototype的方式,前面我说过,内部函数的方式有存在的必要性,但除非必要(比如你要实现一个供setTimeout使用的回调函数等),在javascript中对类实例的方法的标准实现是通过prototype的,这是ECMAScript的规范。当然不是说通过内部函数的方式实现不可以,就是存在内存和效率问题,如果一个类的实例可以预见到不是很多,则无所谓了。如果比较多的话,问题就来了。

    我认为,在Atlas的客户端脚本中存在的某些倾向有一定的问题:
    1. 为了语法的完整大量采用内部函数来实现类方法,前面已经说的够多的了。
    2. 过份强调了严密性而放弃了灵活性和效率。典型的就是对对象属性的实现方式。大量采用了get_ set_ 这样的内部函数。就其好处,当然首先保证了私有变量安全,另外可以对属性的值进行校验,便于扩展,还有就是可以触发事件或者其他的联动计算来保证数据的完整性。另外在解析xml脚本时保证来对属性访问的合法性。PME的概念在.net中可以说时很普遍,也是C#,VB.net等语言固有的特性,但这些并不是javascript固有的特性,可以说javascript语言从设计到发展到标准化(ECMAScript)都不是这个方向,从将来的趋势来看也没有这种趋势。因为客户端脚本的目标和一个编译性语言时不同的,他的特点时简洁、灵活、强大,他存在于宿主环境中,他最主要的目标是操作宿主对象,所以对自身的面向对象的特性方面要弱一些,而且并不严密,存在很多不足。若非要那他来建立一个“坚固”的客户端脚本环境,我不会看好这个方向,或许微软把 Jscript.net强制放在IE环境下会比在jscript中磕磕绊绊地模拟好一些,但这是不可能的。要我来说的话,那些大量的set_ get_ 还是扔了吧,尽管他有不少好处,但和付出的代价来说,太不划算了。

    Atlas的抱负可能太大了一些,依我看,照此路发展下去(不仅仅是客户端脚本),很难成功。当然对于微软来说,没有什么是不可能的,我们还是拭目以待吧。
      回复  引用  查看    
  9. #9楼[楼主] Jeffrey Zhao      2006-09-12 20:02
    @Dflying Chen
    其实这些是选择实现JS类的比较关键的地方。Atlas的目的是完整的在客户端实现一个尽量严谨的OO机制,但是有些地方受限于JS本身导致的不足,而又异常复杂,实现得也不很直观,有种高不成低不就的感觉。因此我把它视为值得一提的缺点。
    在Atlas的“硬伤”之下,还是可以有针对性地进行优化,这个需要大量的琢磨、归纳和努力啊,路漫漫其修远兮……
    我有解析Atlas客户端代码的打算,已经作了一点,我想应该能在这里慢慢给出,如果可以,也希望能归纳出Atlas的Best Practice,目前似乎只有经验得出的零散感觉,却又觉得没有章法……
      回复  引用  查看    
  10. #10楼 Dflying Chen      2006-09-12 20:11
    @Jeffrey Zhao
    优化的余地非常非常地小,呵呵……
    Best Practice就是一句,别用太多UpdatePanel。
      回复  引用  查看    
  11. #11楼[楼主] Jeffrey Zhao      2006-09-12 20:19
    @Dflying Chen
    不过UpdatePanel和类似UpdatePanel的Ajax行为是一个很好的想法,值得学习。
      回复  引用  查看    
  12. #12楼 david8k[未注册用户]2006-09-13 11:25
    Atlas用了太多的javascript 导致其它应用失灵了http://www.cnblogs.com/david8k/archive/2006/09/12/501648.html
      回复  引用    
  13. #13楼 江大鱼      2006-09-13 15:30
    我只用 atlas 客户端和服务器端通信的那部分功能, 比如updatepanel 我不太喜欢用!
      回复  引用  查看    
  14. #14楼[楼主] Jeffrey Zhao      2006-09-13 15:37
    @江大鱼
    UpdatePanel其实是传统的ASP.NET的PostBack模型的一个扩展,事实上在我看来,有些东西,比如会使用大量PostBack的GridView等控件,往往也就是个“演示功能”。事实上大量的项目都使用最基础的HTTP+ASP.NET来使用,不大量依赖于ASP.NET的“方便之处”。使用ASP.NET不能拘泥于GridView这种强大而相对不灵活的控件。
    ASP.NET的很多方便之处,比如使用ViewState来保留State,是靠牺牲性能换来的。
      回复  引用  查看    
  15. #15楼 化工[未注册用户]2006-09-21 03:58
    不应该是这样的吧?@_@~~
      回复  引用    
  16. #16楼 shining[未注册用户]2006-10-04 00:13
    恩,我要把你的链接到我那边!!!
      回复  引用    
  17. #17楼[楼主] Jeffrey Zhao      2006-10-04 02:00
    @shining
    阿?
      回复  引用  查看    
  18. #18楼[楼主] Jeffrey Zhao      2006-10-04 02:01
    @化工
    您是指哪些呢?
      回复  引用  查看    
  19. #19楼 蛙蛙池塘      2006-11-30 22:48
    你的博客从今年10月份才写?我晕,我还是从你的博客的第一篇文章开始看起吧,落的太多了我,你后面的帖子好多看不懂,给个建议,怎么开始学asp.net ajax,我对javascript有一些了解,看过javascript宝典,ajax实战 看了半本了,atlas做过狠简单的例子,没详细研究过,这情况,怎么往下学。
      回复  引用  查看    
  20. #20楼[楼主] Jeffrey Zhao      2006-11-30 23:01
    @蛙蛙池塘
    是的,我在这里起步很晚的:)
    不用从那么早开始哎,有很多CTP的东西,而且我从一开始就是走“深入”路线的。其实ASP.NET AJAX还是ASP.NET,是ASP.NET的一个Extension,大部分情况知道怎么用就可以了。

    其实ASP.NET AJAX的内容不多。
    官方文档已经差不多写全了它的功能了。至于我博客上的内容,都是看它的JavaScript代码或者反编译它的程序集,然后分析的。:)
      回复  引用  查看    
  21. #21楼 蛙蛙池塘      2006-12-01 12:52
    要成为一个优秀的技术人员,所需的技术覆盖之广,其实远超过普通技术人员的想象。

    这句话我也有感触,现在学都学不过来,尤其时候微软这边,更新太快,打算往java那边转,又下不了决心,我打算有时间了把你的blog从头看看,有问题就给你留言了喔。

    问1:Extender是不是扩展的意思呀?就是自己扩展一个客户端控件出来,对吧?

    问2:你说的atlas的bind机制是什么意思,它不需要下载js文件吗?
      回复  引用  查看    
  22. #22楼 蛙蛙池塘      2006-12-01 13:02
    问3:不太明白那哥们说的prototype模式和privilege方法,字面意思是啥意思?

    问4:内部函数的方式怎么就存在内存和效率问题了?


    我感觉上面那哥们的评论也有些道理,客户端脚本为了模拟OO而降低了性能,我们能不能不使用它的客户端脚本呀?
      回复  引用  查看    
  23. #23楼[楼主] Jeffrey Zhao      2006-12-01 14:09
    @蛙蛙池塘
    Extender是ASP.NET AJAX的服务器端组件的一种,用来扩展一个控件的行为,比如增加一些AJAX效果等等。至于Atlas的binding机制,是CTP中经常使用的一个东西,能够在一个属性被改变时自动通知别的组件,这一点在当时很有用,不过现在基本上已经不用了。:)
      回复  引用  查看    
  24. #24楼[楼主] Jeffrey Zhao      2006-12-01 14:12
    @蛙蛙池塘
    prototype是JavaScript用于扩展对象的“标准”方法,是使用以下的方式实现的:
    ClassA = function() {}
    ClassA.prototype={
      method1 = function(){...},
      method2 = function(){...},
      ...
    }

    而privilege方式是这样的:
    ClassA = function()
    {
      this.method1 = function(){...},
      this.method2 = function(){...},
      ...
    }
      回复  引用  查看    
  25. #25楼[楼主] Jeffrey Zhao      2006-12-01 14:15
    @蛙蛙池塘
    其实在模拟OO上,使用Prototype方式是不太会有什么影响的,这就是现在的ASP.NET AJAX使用的方式。而Privilege方式是以前CTP的作法,这样的话每次在初始化一个实例时都会执行大段代码,而且会增加每个对象所占内存,所以会有性能损失。
    也就是说,在使用目前的ASP.NET AJAX时,您可以放心使用OO。以前的CTP和现在已经相差十万八千里了,您可以忽略这些文章。:)
      回复  引用  查看    
  26. #26楼 蛙蛙池塘      2006-12-01 16:12
    这样呀,谢谢,
    Prototype的方法是实例方法,Privilege的也是实例方法吧。你怎么对js这么了解呀,厉害
      回复  引用  查看    
  27. #27楼[楼主] Jeffrey Zhao      2006-12-01 16:30
    @蛙蛙池塘
    它们都是“实例方法”,不过如果在Prototype方式里,对于每个函数只生成一次,调用时自动去prototype里找。而Privilege方式,会为每个对象生成每个函数,这样既费时间又费空间。:)
      回复  引用  查看    
  28. #28楼 蛙蛙池塘      2006-12-02 22:02
    了解了
      回复  引用  查看    
  29. #29楼[楼主] Jeffrey Zhao      2006-12-02 22:16
    @蛙蛙池塘
    :)
      回复  引用  查看    
  30. #30楼 MIKE[未注册用户]2007-03-17 16:32
    :) 学习ing
      回复  引用    



发表评论

昵称: [登录] [注册]

主页:

邮箱:(仅博主可见)

评论内容:

  登录  注册

[使用Ctrl+Enter键快速提交评论]

0 502229 weiV0NCYv9k=



相关文章:


相关搜索:
04. 前端表现 02. ASP.NET

相关链接: