关闭顶部展开顶部

细说.Net开发中的Visual Basic.Net(2)_.Net教程

编辑Tag赚U币
教程Tag:暂无Tag,欢迎添加,赚取U币!

推荐:怎么在ASP.NET中使用SmtpMail发送邮件
在ASP中,就可以通过调用CDONTS组件发送简单邮件,在ASP.NET中,自然也可以。不同的是,.Net Framework中,将这一组件封装到了System.Web.Mail命名空间中。 一个典型的邮件发送程序如下: <%@ Import Namespace=System.Web.Mail %> <script runat=server

易于反编译的中间语言

无论你用VB、C#或其它.NET语言编写应用程序,VS.NET代码都编译成为中间语言(IL)。当应用程序运行时,一个即时编译器(JITter)处理IL代码并把它编译成为机器语言。这意味着在理论上可能为Windows以外的平台创建.NET运行库,但现在关于类似的事情还没有任何官方消息。中间语言的一个缺陷是:它像VB5以前的VB版本一样,容易被反编译。这种可能性使许多开发者普遍地质疑.NET架构的安全性。

CLR在IL层次内外影响代码,对它的修改将使所有使用CLR的语言受益。然而,语言只是和代码如何被解释为IL有关,对特定语言的优化可以根据特定语言的语法来编写,这样在技术上就可能使.NET语言之间的性能差别很小。不管怎样,大体上蓝图是美好的。例如,CLR使VB的调试和监测工具和C#的相应工具相当,它做到了这一点因为它们本来就是相同的工具。

CLR提供不平行的跨语言集成,包括跨语言继承代码的能力。所有使用CLR的语言共享一个通用类型系统,它使使用多种语言开发应用程序变得更简单。我不喜欢把 C API 声明翻译成VB里可以使用的形式,所以我很赞赏通用类型系统带来的好处。

在CLR中运行的代码被称为被管理代码,被管理代码使用的内存完全由CLR来控制。被管理代码带来很多好处,包括跨语言集成、跨语言异常处理和简化的部件相互作用模型。Visual Basic被限制为只能以被管理代码的方式工作,然而C#拥有跳到非被管理代码的能力(执行到运行库之外),并能做像指针操作这类事情。这是VB和C#不同等的情况之一。这种能力到底有多重要取决于你想干什么。

CLR造成的体系结构差别要比跨语言集成、共享功能和被管理代码等深刻。首先,Visual Studio.NET的支撑结构不是 COM。另外,VB.NET里的所有东西,甚至字符串都是对象。因为这些和其它一些原因,Microsoft改变了支撑结构处理对象的方式。COM实现了一个引用计数方案,这样每次引用一个对象时,计数器递增。当一个对象引用超出作用域或被释放时,计数器递减,当引用计数减少到零时就终止这个对象。Microsoft声称在.NET架构下引用计数的开销太大,以至于不能在 .NET中实现它,所以它放弃了引用计数转而使用垃圾收集。

垃圾收集需要新体系结构

CLR垃圾收集器主要是监视一个程序的资源,当可用资源达到确定的阈值时寻找无用的对象,并在发现它们的时候清除这些对象。垃圾收集的一大好处就是你不再需要担心大多数普通的循环引用,即子对象引用了父对象,然后父对象又引用了子对象。在引用计数方案下,循环引用使两个对象都不能被释放和清除。然而,垃圾收集器会发现循环引用并清除它们。这也意味着释放对象的最后一个引用时不再需要立即清除对象。

垃圾收集的一个后果是:你再也不能指望一个类的 Terminate 事件能在适当的时机发出。实际上,如果线程被阻塞,可能根本就不会发出 Terminate 事件。和COM提供的确定化终止相反,它被称为不确定的终止。缺乏确定化终止,以及因为垃圾收集器重新安排并压缩内存从而不能使用指针的事实,在新闻组里激发了一波激烈的辩论。我想这些新限制可能会令你痛恨,因为你要依靠确定化终止;也可能你漠不关心,因为你不依赖 Terminate 事件。垃圾收集并不是万灵药,实现弱引用依然需要做一些考虑。

从引用计数到垃圾收集只是 Visual Studio.NET 的支撑结构不是 COM 这个事实的表象之一。你能在VB.NET中使用COM对象,比如说ActiveX服务器或ActiveX控件。然而,你必须通过包装访问这些对象。任何时候听到“包装”这个术语,你应该明白你面对着性能损失,并且对象的行为可能有所不同。如果当计划移植一个使用了大量COM对象的工程,就需要认真地测试和计划,可能需要重新规划应用程序的结构才能移植成功。坦率地说,你要有遭受挫折的准备。还记得从VBX迁移到 OCX的过程吗?我记得,我的精神病医生也记得。我很快就要再去看他了 ;-)

语言本身的变化要远远超过体系结构的变化。大部分改变确有道理,但我并不认为所有的改变都是如此。以前版本的VB允许你以很多方法来做很多事,以至于统一的编码标准要么不存在要么就很难强加于人。Microsoft对VB做了大量的改变为的就是“清晰”这种语言。很多情况下,原来你有好几种方法做一件事,现在就只有一种了。Billy Hollis 提供了语法变化的详细列表,包括废弃的关键字列表,但有些东西需要在这里重复一下。

首先,向过程参数传递数据的默认方法由引用(ByRef)变成了传值(ByVal)。这个改变主要是因为引用要比传值的风险大得多。它的风险主要是调用过程中的数据可能被无意中篡改。你仍然能通过引用传递数据,但这一改变使你需要修改新的默认调用方法来使用引用。

其次,Set 语句消失了。在 VB.NET 里如果你需要向变量传递一个对象引用,所需要的只是一个等号,对象被视为同其它值一样。这很酷,但也有副作用:默认属性消失了。例如,你不再能用这种方式引用一个属性:

以下是引用片段:Text1 = "What, me worry?"

作为替代,你必须显式地引用属性:

以下是引用片段:Text1.Text = "What, me worry?"

也许一眼看来不需要这种改变,但确实必须去掉默认属性。例如,假定你有一个叫objFoo的对象变量,不用Set语句,下面的语句所设置的引用就产生了歧义性:

以下是引用片段:objFoo = Text1

这条语句是应该设置到Text1的引用,还是以Text1的Text属性来填充objFoo?你不能确定,编译器也不能。抛弃Set语句同时要求抛弃默认属性。

有一个改变我不喜欢:你不再能在不同的作用域里声明Property Get和Property Set过程。注意 VB.NET 没有 Property Let 语句:对象和数值都用 Property Set。这意味着你不能用一个 Friend Property Let 过程来对应一个 Public Property Get。用VB建立组件时可能会有麻烦。许多组件开发者创建 Friend Property Set 过程以使他们的应用程序能改变一个值,但提供 Public Property Get 过程以使他们的客户程序能取回值。我希望我能为这个改变找到一个合适的理由,可是我找不到。

分享:谈.Net和Java的socket机制比较
socket是基于TCP和UDP协议的高层接口,定义了收发数据的格式。Java的TCP服务中使用的Socket是一种流机制,即对于编程人员来说,处理socket只需要从Socket中获取流,然后可以像处理本地流一样来进行数据的收发。 例如: DataOutputStream outToClient =new D

来源:模板无忧//所属分类:.Net教程/更新时间:2009-03-02
loading.. 评论加载中....
相关.Net教程
闂傚倷鐒﹂惇褰掑春閸曨垰鍨傞梺顒€绉甸崑銈夋煛閸ヨ埖绶涚紓宥嗙墵閺屾盯鍩勯崘顏佸闂佹娊鏀辩敮妤呭Φ閸曨垰鍗虫俊銈傚亾濞存粍鍎抽—鍐Χ韫囨洜肖闂佺懓鍤栭幏锟�
濠电姷鏁搁崑娑㈩敋椤撶喐鍙忔い鎾卞灩绾惧鏌熼悙顒佺伇婵℃彃鐗撻弻锟犲磼濠靛洨銆婃繝鈷€鍕姇濞e洤锕幊鐘活敆婢跺棗浜炬繝闈涱儐閻撶喖鏌曡箛濠冩珔闁诲繑鐓¢弻鐔煎礄閵堝棗顏�
濠电姷鏁告慨鐑姐€傛禒瀣劦妞ゆ巻鍋撻柛鐔锋健閸┾偓妞ゆ帒瀚峰Λ鎴犵磼鏉堚晛浠滄い鎾冲悑瀵板嫮鈧綆浜濋楣冩煟鎼达絾鍤€閻庢凹鍘界粩鐔煎幢濞嗘劕搴婃繛鎴炴煣缁舵岸寮婚敐澶婎潊闁宠桨鑳舵导鍫ユ⒑閻熸澘娈╅柟鍑ゆ嫹
濠电姷鏁告慨鐑姐€傛禒瀣劦妞ゆ巻鍋撻柛鐔锋健閸┾偓妞ゆ帒瀚峰Λ鎴犵磼鏉堚晛浠滄い鎾冲悑瀵板嫭绻濋崟闈涙倯闂傚倷娴囬鏍垂鎼淬劌绀嬫い鎾楀嫅姘舵⒒娴g瓔鍤欓梺甯到宀h儻顦查摶鐐寸箾閹存瑥鐏柛瀣樀閺屻劑鎮ら崒娑橆伓
闂傚倸鍊烽懗鑸电仚缂備胶绮崝娆撶嵁婵犲啯鍎熼柕濞垮劤閸旓箑顪冮妶鍡楃瑨闁稿﹤鎽滈弫顕€宕奸弴鐐殿啇闁诲孩绋掑玻鍧楁儗閹烘柡鍋撶憴鍕缂佽鐗撳顐﹀箻缂佹ɑ娅㈤梺璺ㄥ櫐閹凤拷
闂傚倸鍊烽懗鑸电仚缂備胶绮崝娆撶嵁婵犲啯鍎熼柕濞垮劤閸旓箑顪冮妶鍡楀潑闁稿鎹囬弻娑橆潩椤掑鍓崇紓渚囧枛閿曨亪寮崒鐐茬鐟滃繘鎮¢幘缁樼厽閹兼惌鍨冲畝娑㈡煛閸涱喚绠為柟顖氳嫰閳诲酣骞嬮悩纰夌闯濠电偞鎸婚懝楣冩晝閵壯€鍋撳鐐
闂傚倸鍊峰ù鍥Υ閳ь剟鏌涚€n偅灏伴柕鍥у瀵粙濡歌濡插牓姊烘导娆忕槣闁革綇缍佸璇测槈濡攱鏂€闂佸綊鍋婃禍鐐烘嚄閾忓湱纾藉ù锝夋涧婵¤姤淇婇悙鑸殿棄妞ゆ洩缍佹俊鎼佸煛婵犲啯娅栨繝鐢靛仜濡瑩宕归悽鐢电當闁跨喓濮甸埛鎴︽煕濠靛棗顏╅柍褜鍓欓…鐑界嵁婵犲洤绠婚柤鍛婎問濞肩喖姊虹捄銊ユ珢闁瑰嚖鎷�
闂傚倸鍊风粈渚€骞栭锕€鐤柣妤€鐗婇崣蹇擃渻鐎n亝鎹g紒鈧繝鍌ょ唵闁兼悂娼ф慨鍫ユ煟閹垮嫮绉柟顔款潐濞碱亪骞忓畝濠傚Τ婵犵數鍋涢惇浼村磹閺囥垺绠掗梻浣瑰缁诲倸螞濞嗘垹鐭嗛柍褜鍓熷娲川婵炴碍鍨块幃褔鎮╅懠顒佹闂佽澹嗘晶妤呭疾閹间焦鐓ラ柣鏇炲€圭€氾拷
婵犵數濮烽。钘壩i崨鏉戝瀭妞ゅ繐鐗嗙粈鍫熺節闂堟稒锛嶉柣鏂挎娣囧﹪顢涘顒佸€柣搴㈡皑缁垶濡甸崟顖氱閻庨潧鎽滈悾娲煟鎼淬垻鍟查柟鍑ゆ嫹
濠电姷鏁告慨鐑姐€傛禒瀣劦妞ゆ巻鍋撻柛鐔锋健閸┾偓妞ゆ帒瀚峰Λ鎴犵磼鏉堚晛浠滄い鎾炽偢瀹曞爼濡搁妷顔荤穿濠碉紕鍋戦崐鏍箰閼姐倖宕查柛鎰典簴閸嬫挸顫濋搹顐ゅ涧婵烇絽娲ら敃顏堛€佸☉妯滄棃鍩€椤掍焦娅犻柛娆忣槺缁♀偓濡炪値鍋掗崰妤冣偓姘炬嫹
婵犵數濮烽。钘壩i崨鏉戝瀭妞ゅ繐鐗嗙粈鍫熺節闂堟稒锛嶉柣鏂挎閹便劌顪冪拠韫闁诲氦顫夊ú锕傚礈閻旂鈧礁鈻庨幘宕囶槯闂佺粯鎸哥花鍫曞磻閹剧粯鍋ㄩ柛娑橈功閸樻悂姊洪崜鎻掍簼缂佽瀚悺顓炩攽閻樻剚鍟忛柛锝庡灦楠炲繘鏁撻敓锟�
婵犵數濮烽。钘壩i崨鏉戝瀭妞ゅ繐鐗嗙粈鍫熺節闂堟稒锛嶉柣鏂挎閹便劌顪冪拠韫闂備礁鎼懟顖炲箠濮椻偓瀹曟椽鍩€椤掍降浜滈柟鍝勬娴滈箖姊虹€圭媭鍤欓梺甯秮閻涱噣骞嬮敃鈧粻娑㈡⒒閸喓鈯曟い鏂挎濮婄粯鎷呴崨濠冨創闁诲孩纰嶉幃鍌炵嵁韫囨稒鏅搁柨鐕傛嫹
婵犵數濮烽。钘壩i崨鏉戝瀭妞ゅ繐鐗嗙粈鍫熺節闂堟稒锛嶉柣鏂挎閹便劌顪冪拠韫闁诲氦顫夊ú鈺冪礊娓氣偓閻涱喚鈧綆浜栭弨浠嬫煕椤愵偄浜楃紒鎲嬫嫹
濠电姷鏁告慨鐑姐€傛禒瀣劦妞ゆ巻鍋撻柛鐔锋健閸┾偓妞ゆ帒瀚峰Λ鎴犵磼鏉堚晛浠滄い鎾冲悑瀵板嫭绻濋崟顓炲箑闂傚倷鑳堕幊鎾绘偤閵娧勫床闁告洦鍨奸弫鍌炴倵濞戞鑲╂崲閸℃ǜ浜滈柡宥庣厛濞堟柨顭胯瀵墎鎹㈠┑瀣剁稏妞ゆ棁妫勯锟�
闂傚倷娴囬褎顨ラ幖浣稿偍婵犲﹤鐗嗙粈鍫熺節闂堟侗鍎愰柛瀣儔閺岀喖骞嗛悧鍫闂佹椿鍘介〃鍛村煘閹达附鍋愰柟缁樺笚濞堫參姊烘總鍛婃锭缂傚秴锕濠氬Χ婢跺娈熼梺闈涱槶閸庨亶锝炲澶嬧拺缂備焦岣挎竟鍕磽瀹ュ嫮顦﹂柣锝呭槻閳诲酣骞樼€涙ɑ顏熼梻浣芥硶閸o箓骞忛敓锟�
UB闂傚倸鍊风粈浣革耿鏉堚晛鍨濇い鏍仜缁€澶嬩繆閵堝懏鍣界€规挷绶氶弻娑㈠Ψ閵忊剝鐝曢柣搴㈢瀹€鎼佸箖濡も偓閳藉鈻嶉搹顐㈢伌闁挎繄鍋ら弫鎾绘晸閿燂拷
闂傚倸鍊峰ù鍥ㄧ珶閸喆浠堢紒瀣儥濞兼牕鈹戦悩宕囶暡闁绘帡绠栭幃妤呮偨閻㈢偣鈧﹪鏌涚€n偅宕岄柣娑卞櫍瀹曞綊顢欓崣銉ф/濠电姷鏁告慨顓㈠磻閹剧粯鐓ラ柣鏇炲€圭€氾拷
闂傚倷娴囬褎顨ラ崫銉т笉鐎广儱顦崹鍌炴煕濠靛棗顏甸柤鏉挎健閺屾盯濮€閵忕姵顔�
闂傚倸鍊风粈渚€骞夐垾鎰佹綎缂備焦蓱閸欏繐顪冪€n亝鎹g紒鈧繝鍌ょ唵閻犻缚娅i悘閬嶆煕濡や胶顣茬紒缁樼洴瀹曞崬螖閳ь剟顢楅姀銈嗙厱闁绘劕妯婂Σ鍦磼缂佹ḿ銆掔紒杈ㄧ懇閹晠宕崟顐㈣厫闂傚倷鑳舵灙濡ょ姴绻橀獮蹇涙晸閿燂拷
缂傚倸鍊搁崐鎼佸磹閻戣姤鍊块柨鏇炲€归崑锟犳煥閺囩偛鈧悂宕归崒娑氱瘈濠电姴鍊搁顐c亜閳哄懏鏁遍柕鍥у楠炴帒顓奸崶鑸敌滅紓鍌欑劍瑜板啫锕㈤柆宥呯劦妞ゆ帒鍊告禒顖炴煕婵犲啰绠樼紒杈ㄦ尭椤繃锛愬┑鍥ㄦ珦闂備浇娉曢崳锕傚箯閿燂拷
©2017 www.mb5u.com婵犵數濮烽。钘壩i崨鏉戝瀭妞ゅ繐鐗嗙粈鍫熺節闂堟稒锛嶉柣鏂挎閹便劌顪冪拠韫闁诲孩顔栭崳顕€宕抽敐澶婄畺闁冲搫鎳庣粻鐢告煙閻戞ɑ灏柣锔兼嫹
闂傚倸鍊峰ù鍥Υ閳ь剟鏌涚€n偅宕岄柡宀€鍠栭、娑樷堪閸愮偓姣夋俊鐐€戦崕濠氬箯閿燂拷&闂傚倸鍊风粈渚€骞夐敍鍕殰闁圭儤鍤﹀☉銏犵睄闁割偆鍣ュΛ鍛存⒑鐠恒劌娅愰柟鍑ゆ嫹