如题,大家有什么好点的框架和相关的学习资料给我提供一点.小弟万分感谢
解决方案 »
- [.NET] Literal与Ajax关联
- updatepanel 和 输出特俗字符串(乱码)的问题
- 菜鸟求助,请问GridView控件的外观能用页面的CSS文件来统一定义吗
- 一个简单问题,请大家帮忙看看
- 第一回在JS区提问,带指向的提示如果作呢?? 分不多,80分
- 需要做购物车的朋友,给一个我做的小程序,没准用的上 :)
- asp.net中弹出保存文件的对话框
- DataGrid1.DataKeys[item.ItemIndex和DataGrid1.Items[e.Item.ItemIndex]有什么区别啊??
- 请教关于javascript的使用问题
- 请教有关aspnetmenu超链接问题
- sql2005中 "默认值或绑定"的用法
- 请大家谈谈使用ASP.NET AJAX(Atlas)的心得体会经验
Atlas的整体架构分为客户端和服务器端两部分。客户端的框架和服务包括:封装浏览器之间差异的浏览器兼容层、包括一个javascript整套类体系的脚本内核、一个较为完整的基类库、一套组件及相应的组件模型和UI框架。服务器端框架包括:网络服务桥、应用服务桥、一个以ScriptManager为基础的服务器控件框架等等。Atlas力争使人们编写ajax应用程序与编写asp.net Web Form应用程序类似。在服务器端将atlas的声明脚本发送给客户端,然后页面在atlas客户端框架下运行,使用atlas服务代理,客户端直接连接Web Service或Windows Communication Foundation (WCF)服务,给用户带来更丰富的客户端体验。Atlas架构大大减少了开发者所需的代码量,进而提高了开发效率,因为服务器端控件已经为你生成了大量的代码。这种架构将页面中的内容、样式、行为和代码清晰地分开。客户端直接调用Web服务或WCF服务,这样就避免了使用中介层对通信效率的影响,同时也避免了增加中介层对应用程序设计、实现和部署中带来的复杂性。但也就因为他过分的依赖这些并不完全成熟和可扩展的服务器端控件,使得其灵活性大大减弱。微软一直把我们当成傻瓜,竭尽所能的为我们做所有工作。显然,这次他又失算了。虽然atlas嚷嚷的轰轰烈烈,但人们多半是把他当玩具拿来玩玩而已,还没有多少人敢用他来做真正应用的东西。相反,由Michael Schwarz自己开发的ajax.net却悄无声息的广为流传着,并且屡屡被人拿来做一两个小东西。原因很简单:ajax.net可以更好的发挥我们的能力,而atlas却只能更好的发挥微软的能力。当然,上面说的是微软的早期版本。Atlas一直在进步,也越来越让我们喜欢了。今年9月份,Scott发布的Atlas命名和开发计划的文章,又给我们带来了两个好消息:
wwHoverPanel AJAX Control for ASP.NET是一个ASP.NET的控件,但是提供了客户端回调(高级回调)、客户端调用页面方法,以及双向两路的序列化功能。,wwHoverPanel设计简单,而且是基于控件不依赖HTTP Model和ASP.NET Page Pipeline,也不依赖ViewState。 JSON的双向序列化是一个不错的方案,但高性能的场景下,应该考虑实现更高效的序列化框架AjaxAspects是个可以用Javascript调用服务端WebService事件的引擎。他用标准的SOAP和WSDL进行服务端-客户端通信 ;用简单的类型和XML对象支持带参数的返回值 ;支持缓存和动作队列。 第二部分:理想中的ajax平台展望。 Asp.net下的Ajax平台发展到现在,基本上已经形成了一些共识:ASP.NET控件形式成为连接服务器和客户端Ajax通信的主要形式和选择;客户端调用服务器端页面中的方法是Ajax的重要手段,使得客户端可以更加灵活的获得服务器端的数据;Ajax 要求有足够的力量关注前端的UI展现或开发,所以Ajax框架必须提供多样的客户端的实现以及Web UI有的人说,目前流行的Ajax-NET的框架或实现都是Add-in (Plug-in)的模式的,也就是说这些框架对于使用传统的ASP.NET的应用架构(或准备用ASP.NET v2.0开始创建新的应用)是非常有利和方便的。而今后,最有可能开发出一套完整ajax解决方案的很可能是微软。一个完善的ajax框架或开发平台,至少应该解决这么几个问题:表现层展现的问题;双向两路的序列化问题;传输时客户端和服务器端的数据安全问题; 性能问题; 国际化支持;搜索引擎的友好问题。ajax平台的开发绝对是一个复杂性颇高的系统工程,需要大量人力,财力的投入。那么,ajax平台应该是什么样子呢?从使用者的角度,个人认为未来的ajax平台应该具备这么几个特点:自动生成JavaScript基础库。Javascript对ajax的份量不言而喻,如果有这样一个Wizard,我们能够选择针对的浏览器平台、版本、完备的功能列表等,然后它就能帮我们生成一个已经优化了的JS文件。那是多么令人憧憬啊;智能调试javascript。让我们不再畏惧js;智能的CSS优化。让可重用css规则得到最大限度的重用,最好能够让我们鼠标点几下就一切ok了;全方位的重构支持。不止javascript,还包括dhtml,css的重构;界面操作可视化; 集成各种UI组件库;当然,完善的单元测试支持也必不可少。 就象有人描述的那样,未来的技术人员,将不用谈论什么Web 2.0,就可以清楚的表达Ajax的概念 ;未来的架构师,也不再认为Ajax是什么异步的XMLHTTP调用,是什么不刷新页面,它只是一种可以帮助他们Review应用程序的架构; 对未来SOA的爱好者来说,Ajax架构让他们能够站在面向消息的架构和系统上来看面向服务…….这就是我们所希望看到的。 .net框架下的ajax是这样,所有的ajax框架都应该是这样。
http://www.msdnwebcast.com.cn/CourseSeries.aspx?id=74
回答这个帖子的
http://community.csdn.net/Expert/topic/5436/5436423.xml?temp=.7867548
感觉没有什么好说的了关于ajax曾经给公司内部做过一个培训,当时也是稍微总结了一下,不过就讲了一些基本的知识,ajax的产生背景,意义,优点,不足以及属性和方法的含义,包括一些简单的例子,并没有深入去讲(实际上是没什么深入的,xmlhttprequest对象也就那几个属性和方法,没什么太多讲的),手稿地址贴在blog上面了,地址为:http://www.cnblogs.com/ustbwuyi/archive/2007/02/08/645061.html后来为了加深员工对ajax技术的深入应用,写了个ajax的例子,当时也是解决老总提出的一个问题...贴在
http://www.cnblogs.com/ustbwuyi/archive/2007/03/19/679586.html
一般来说,ajax的框架现在非常多,刚开始我一般用ajax.dll,ajaxpro.dll,magicajax.dll之类的,Atlas用到的时候不是很多,感觉这几个框架还是算比较好用的,ajax.dll,ajaxpro.dll都比较灵活,magicajax.dll功能更强大但稍嫌臃肿,封装了很多不必要的功能。至于MS推出的那些框架如Atlas,感觉和magicajax差不多,并没有感到特别的地方(可能是用得少,没发现)。
现在看起来,觉得还是手写xmlhttp比较好,灵活性上非常好控制,另外,那些所谓的ajax框架一般似乎都没解决浏览器兼容问题,曾经反编译ajax.dll,发现没有解决浏览器兼容问题,不知道现在怎样,至于微软推出的Atlas,不用想肯定只支持IE,而自己手写就不会有这个问题。
另外,觉得ajax只是web开发中一个小小的点缀,偶尔用之,小地方用之(这是它的先天缺陷注定的,关于这些在我第一篇文章里阐述)自己随便创建个xmlhttprequest对象即可,何必大张旗鼓去添加dll,配置webconfig,忙得不亦乐乎?
我的blog里面有两篇入门的
http://blog.csdn.net/ivy_zheng
自己写 或 ajaxpro
2.0中用Atlas
遇到一个问题,迷茫迷惑中