|
马上注册,结交更多好友,享用更多功能,让你轻松玩转社区。
您需要 登录 才可以下载或查看,没有帐号?立即注册
x
我有个同学,他是搞net网页编程的,他给我说“net网页编程不是效率低,而是速度慢。”,我不是搞net网页编程的,我实在想不透这句话的含义,难道执行速度不就是效率低吗?难道执行速度慢还成效率高了? 我撰写.NET手艺通信已有约莫三年工夫,如今我决意中断这项事情。我以为有需要写一篇总结性的文章,论述我对.NET以后情况及将来开展的意见。
2000岁首,当.NET还在Beta版的时分,我就入手下手利用它了;在谁人时分,它的称号是COM+2,次要的言语是Cool。其框架组件被复杂地称为下一代Windows服务(NGWS),直到厥后才由市场人士提出.NET这个称号,可是.NET这个名字却使互联网搜刮引擎发生了凌乱。你自问过.NET究竟是甚么意义吗?抑或它与.COM和.ORG有甚么干系吗?固然,Cool的遭受也好不到那儿往。厥后他们有了一些灵感,决意把Cool改名为C#,可是C#仿佛最后也引发了搜刮引擎和用户的凌乱。搜刮引擎不喜好利用#字符,而用户则不晓得这个字符该怎样读(C磅?仍是东方的发音C号?)。我宣布在手艺旧事组上的第一篇文章是一个复杂的Cool把持台使用程序、一个与其功效相称的Java程序,并提出一些成绩指出了二者之间的不同。这引发了VisualStudio产物司理的激烈呼应,他们没有真正地注重到我所指出的成绩。
VisualStudio.NET与VisualStudio别的的版本分歧,它的第一个beta版是开放的。任何人都能够下载并在beta旧事组中提交bug或成绩。厚道说,我不喜好这类体例。我只是在大众旧事组中宣布了一些可反复的bug,作为一个沉默的英国人,我不喜好宣布那些不成反复的bug,也不喜好提出改良倡议。我也没有看到关于这个年夜局限的、开放的beta版是不是从发明的大批bug中受害的公然宣布的了局;但是,我嫌疑查找bug并非其目标--更大概的情形是beta版的开放是为了使它尽量的被人人承受。
我与其别人一样,入手下手的时分也被该框架组件的巨细吓住了。它太年夜了!在已往的几年中我得出了一个结论:框架组件的巨细是一种停滞。它内里的类太多了,只管我也以为个中良多类是被优秀地计划的,可是我仍旧以为有一些是轻率地完成的。个中有些类仅仅对Win32的复杂包装,另有一些类看起来是从别的的框架组件中导进的。微软在公布.NET之前,已具有本人的Java框架组件类库(叫做WFC),还具有一个传统的VisualBasic运转时部分的受控(managed)类库,假如我晓得有几WFC和VB类迁徙到了.NET上就行了。但我可以辨认出个中的一个,由于它在.NET和VB上运转的情形一样糟,这个类就是EventLog。这个类的举动与它在VB中的举动一样,在依照惯例迁徙到框架组件1.0版本之前,乃至于没有人体贴它的计划。我在beta版中就埋怨过这个类,可是这个类的开辟者只给出了一些毫无压服力的来由。最初,这个类在2.0中举行了“修补”,可是毛病的办法仍是没有被打消,因而我以为它基本就没有被“修补”过。
整体来讲,我以为这个类库公布得太早了,同时它还太年夜了。该框架组件的可从头公布的部分(redistributable)有25MB,它比Java的可从头公布部分年夜良多倍。VisualBasic初期版本得出的履历是共享软件和收费软件市场作育某种言语的盛行。只管有些共享软件是利用.NET编写的,可是我常常听到人们埋怨谁人伟大的可从头公布部分。我写过关于类库巨细成绩方面的文章,而且我一直以为假如微软供应删减过的、只带有微软中心类库和体系部件的框架组件版本是有优点的。
提及VisualBasic,我也想提出本人对它的意见,我不能不说传统的VisualBasic太老了。该言语生成就是单线程的,与COM交互(和创建COM服务器)时会发生很严峻的成绩。实践上,在我写完一本关于MTS的书(1999年宣布)的时分,就得出结论说MTS被计划为同意VisualBasic开辟职员编写那些能够从多线程手艺(threading)和平安手艺(security)中受害的对象,而COM+则使其更进一步了。VisualBasic能够挪用Win32函数,可是为了高效力利用这些函数,一般必要使用不太好的黑客手艺。可是有了COM和COM平安手艺以后,它向前迈进了很年夜的一步,不外仍是不克不及用大批的几行代码来供应C++可以完成的功效。C++能够用很少的代码就可以便利地完成而VB却没法像如许,完成任何功效都使VB十分困顿。可是这类言语和在运转时(runtime)发生的年夜多半成绩都是与生俱来的,因而,这些成绩的办理计划十分保守。这招致了VB.NET的呈现。
假如你搜刮互联网,就能够找到良多关于VB.NET的公布激发狂热的材料。最好的是KarlE.Peterson的网站(http://www.mvps.org/vb/rants/vfred.htm)。但VB.NET几乎就不是VB:Karl的网站显现在VB和VB.NET两种言语之间良多工具是不兼容的。别的,VB是单线程的,它不带非常处置,并且典范情形下是用于编写非OOP代码的。VB.NET带有一个"迁徙"工具,可是我熟悉的利用过这个工具的年夜多半人都发明这个工具仅仅复杂地标志出了大批的不兼容的代码。我初期的倡议是VB开辟者不要迁徙本人的代码,替换的办法是,把代码转换为VB类,而这些类则能够经由过程COM交互操纵(interop)而被.NET代码挪用。接纳这类办法,VB代码仍旧能被保存在计划情况中。固然,微软持续说VB.NET就是VB的神话,勉励人人利用这个迁徙工具。
有些人以为VB.NET是使人叹服的。可是我真的没有发觉计划这类言语的念头。在VB.NET中别的言语所不具有的特征很少(除过滤器和接口办法的重定名),可是这关于发生一种新的言语来讲来由是不充实的。有些人大概会说VB开辟者利用VB.NET加倍随手,可是我后面说过,VB.NET不是VB,因为开辟者必需进修OOP和.NET的道理,比方线程手艺、非常处置和托付,开辟者差未几进修了一门新的言语。C#是一种天然的能够用于.NET的言语,基本就不必要VB.NET。利用分号(;)和括号({})没有那末坚苦!它能够作为VB.NET的取代者,可是并不是一切的言语都是如许的。我的意见是,通用言语标准(CLS)仅仅是复杂地确保了在别的的言语中能够创建与VB.NET代码一同事情的代码,而不是使一切的言语协同事情。我晓得有标记的(signed)整型数据是有效处的,可是无标记的(unsigned)整型数据也有效啊!我就不睬解为何VB.NET不把无标记整型作为言语的一部分。另有一些情形也是稚嫩的,我们没有来由利用OptionStrictOff("提早绑定"也与难以查找运转时bug是同义词),并且假如你没有显式地(explicitly)声明变量,那末很简单得到对这些变量的跟踪。VB.NET带来的大批上风不敷以抵消它所具有的这些严峻的缺点。
我已经写过VB.NET的文章,也在VB.NET会商会上讲话过,因而我很懂得这类言语。可是,它并没有使我感应温馨:我发明本人每次利用这类言语的时分,都少不了唾骂。它事情的情形就是与我预期的纷歧样,并且我也不是独一的碰到这类情形的人。这是传统的VB迁徙到VB.NET的时分我听到的最多见的埋怨,这也撑持了KarlE.Peterson的断言--VB.NET不是VB。那末微软为何创立VB.NET呢?其缘故原由是在2000年的时分,VB开辟职员的数目凌驾了微软的别的言语、凌驾C++用户数目最少10%(我在微软外部集会上看到过这个图表)。微软高调地公布C#是"来自C++家属"的另外一种言语,而且市场人士以为他们不成能使一切这些VB程序员都利用相似C++的言语。替换办法是,他们以为假如微软创建一品种似VB的言语,这些VB程序员中相称比例的人更有大概迁徙到.NET上。换句话说,VB.NET的呈现是市场的缘故原由而不是手艺的缘故原由。
有需要指出,.NET大致上与传统的VB有良多类似的地方。.NET与VB一样可使用接口(interface),接口长短常精巧的(elegant),可是.NET却保举利用基于类的办理计划,这标记着接口的灭亡。
我们再来看一看.NETremoting(远程手艺):微软供应.NETremoting用于同意创立于本人的情况中而且运转着的对象被另外一个情况挪用。这意味着该对象的形态是当地的(local),而它的举动则是远程的(remoted)。因而,remoting是一个基于接口的工具。你能够使用接口来利用.NETremoting,可是假如你浏览文档大概会见Web上的"how-to(操纵指南)",你就基本认识不到这一点。作为取代的是,微软保举人们利用基于类的办法,这一般会招致一些奇异的征象呈现--人们向客户端部署服务器部件,如许客户端才具有可用的服务对象的元数据(metadata),大概招致泡沫部件,它使哪些基于类的remoting成绩到处散布。
.NET十分象VB的另外一个中央是微软对它的框架组件的立场。微软把.NET作为扩大本人的产物的一个有效的类库,可是到今朝为止,微软却没有显现出对该框架组件的更年夜的信念。今朝只要很少的.NET产物是全部地利用.NET编写的;个中一个是微软的CRM。可是,它们却不是微软次要的支出来历。作为取代,.NET被更新到已有的产物中,并用于扩大这些产物。即便VisualStudio.NET也不是.NET产物。devenv.exe是一个用C++(也许是MFC)编写的非受控(unmanaged)历程。VS.NET投止了.NET运转时,如许它就能够利用相似属性表格的.NET对象,而且它能够被写成.NET部件的代码扩大。我以为这是微软将来利用的模子。他们不但愿承当为.NET从头编写代码的开支,并且没有谁强制他们在.NET中供应全新的代码;.NET将会被投止,而且在必要的时分,同意经由过程用户供应的代码来举行扩大。
微软以后的操纵体系XP和Windows2003其实不依附于.NET;并且XP中.NET是一个可选组件。下一个版Windows(叫做Longhorn)在2003PDC上作为手艺预公布过,看起来.NET贯串着这个操纵体系。可是到公布的时分会产生良多变更的。在已往的一年中,微软宣布了良多声明,体现出它更体贴原定的公布日期2006年,而不是对新手艺的热忱。第一个停滞是WinFS,很分明这类手艺会使Longhorn更慢,出格是WinFS使OutlookExpress基本就没法利用。可是微软的做法并非使这类手艺可以一般事情,而是选择删除它。在你浏览这几行的时分,我在嫌疑这类手艺是不是可以前往使用。其次,微软传播鼓吹Longhorn中的别的两种.NET手艺--Indigo和Avalon,将能够在别的版本的Windows中利用。Indigo是一种通信手艺,因而别的版本的Windows利用它是成心义的。可是,我以为使Avalon可用于别的版本的Windows标明微软对Longhorn的发卖不太自傲。
我的意见是Avalon--更详细地说是XAML,将标记着ASP的灭亡。其缘故原由在于Avalon是一种客户端手艺,而扫瞄器则是该散布模子的一个主要部分。XAML的功效云云丰厚,以致于包括扫瞄器的XAML使用程序与基于历程的Avalon使用程序看起来没有不同,并且与Web服务大概Indigo(作为会见远程代码的机制)耦合以后,XAML使用程序会使ASP.NET使用程序看起来毫无代价和陈腐不胜。微软为何想毁失落ASP呢?安装ASP.NET的时分,微软会卖出一套Windows2003,同时还大概卖出几套VisualStudio.NET。客户端能够不是Windows,因而微软不会有别的的发卖支出(不管是产物也许可)。这是一块很年夜的支出来历,更糟的是,ASP.NET实践上使编写使用程序加倍简单了,并且它还能够被IE之外的扫瞄器利用。可是,利用相似XAML手艺的时分,微软对客户端有把持权。因而,除服务器和开辟工具以外,客户端也必需具有Avalon手艺。假设客户被压服了,晋级到Longhorn,那末它便可能是微软伟大的支出来历。可是微软传播鼓吹Avalon将能够用于别的版本的Windows,向我标明他们对Longhorn的估计也不是那末自傲,而且假如开辟者不克不及断定客户端是不是会运转Avalon使用程序,那末他们就不会为Avalon编写使用程序。
因而,从客岁的声明中能够看出,微软以为Longhorn并非在PDC2003上获得我们信托的巨大的.NET厘革。这标明微软正在慢慢得到对.NET的信念。当我看到Longhorn的beta版的时分(应当是往年岁暮),我会细心地反省它究竟有几是用.NET完成的。我嫌疑只要很少的一部分会用.NET来完成。我们能够找到一些线索:假如Longhorn没有完成命令注释程序(shell),大概不同意你用.NET扩大命令注释程序,那末很分明微软得到了信念。假如Longhorn没有完成.NET中的任何服务,那末就标明.NET并非在LOCALSYSTEM帐号权限下运转的准确的手艺。
你读到这儿时分,失掉的印象多是我对.NET的意见是愤世嫉俗的。它的框架组件有良多答应,可是我以为微软的野心太年夜,以太快的速率公布了太多的部件。微软为了供应向后的兼容性,不克不及复杂地从头计划全部类库并丢弃旧的类库。因而我们得保持利用如今所具有的类库。微软同意市场优先于手艺:他们创建并宣扬VB.NET仅仅是为了使Windows开辟职员利用.NET,而不是由于必要这类言语。它的框架组件酿成了VisualBasic--它是供用户开辟使用程序的,而不是供微软创建操纵体系或创建他们所依附的带来支出的产物的。在经过全球个人PC市场占有90%的微软对asp.net不断优化与整合后,asp.net与微软自身平台的动用上更加的高效,加上asp.net在应用上非常容易上手,相信asp.net仍会是最多客户选用的脚本语言,并会在未来几年继续领跑。 |
|