在.net framework平臺(tái)下開(kāi)發(fā)組態(tài)軟件

最初接觸.net framework的時(shí)候是2002年，那時(shí)還是beta版本。看到微軟描述的.net framework未來(lái)的規(guī)劃藍(lán)圖后，被蓋茨忽悠的熱血賁張，感覺(jué).net是未來(lái)的發(fā)展方向，并可以解決當(dāng)前用戶所遇到的一些問(wèn)題。當(dāng)時(shí)還給國(guó)內(nèi)的一家知名的組態(tài)軟件廠商提交了一份研發(fā)報(bào)告，可惜沒(méi)被采納。

說(shuō)實(shí)話，剛開(kāi)始利用.net開(kāi)發(fā)工控軟件的時(shí)候還是存在諸多擔(dān)心，主要擔(dān)心有以下幾點(diǎn)，與各位博友分享：

性能問(wèn)題

由于.net framework是在API上又封裝了一層，因此無(wú)疑會(huì)帶來(lái)運(yùn)行效率上的問(wèn)題。而對(duì)于工控軟件，程序的運(yùn)行效率又是極為關(guān)鍵的要素之一，這是我們當(dāng)初所最為擔(dān)心的地方。事實(shí)上，影響程序運(yùn)行效率的最關(guān)鍵因素在于系統(tǒng)架構(gòu)和編碼人員。有資料顯示，采用C++編寫(xiě)的程序與采用C#編寫(xiě)的程序在性能上相差無(wú)幾，相對(duì)于程序員水平和對(duì)系統(tǒng)運(yùn)行效率重視程度而導(dǎo)致的差異幾乎可以忽略不計(jì)。

想當(dāng)初聽(tīng)說(shuō).net的裝箱拆箱操作對(duì)系統(tǒng)性能影響較大，而在程序中對(duì)數(shù)據(jù)進(jìn)行了特殊處理，現(xiàn)在看來(lái)完全沒(méi)有必要。一來(lái)到了.net framework 2.0裝箱拆箱效率有了較大改善，二來(lái)這樣的設(shè)計(jì)對(duì)于程序的擴(kuò)展性有較大的影響。

開(kāi)發(fā)資源問(wèn)題

經(jīng)過(guò)廣大程序員的努力，目前在windows平臺(tái)下積累了大量可重用性資源，如各種組件、ActiveX控件等等，這也是windows平臺(tái)下軟件開(kāi)發(fā)的優(yōu)勢(shì)之一。當(dāng)初我們擔(dān)心在.net平臺(tái)下開(kāi)發(fā)資源太少，加上工控軟件一般來(lái)說(shuō)會(huì)比潮流慢半拍，所有工作都需要自己來(lái)做，這是我們所擔(dān)心的地方。

事實(shí)證明，我們的這種擔(dān)心也是多余的。大家可以看到，目前在.net平臺(tái)下的編程隊(duì)伍飛速擴(kuò)展，各種winform控件不斷推出。就連著名的ComponentOne也很快推出了.net下的控件集。

此外需要說(shuō)明的是.net對(duì)過(guò)去的com和ActiveX控件同樣支持，在發(fā)布的易控軟件中，可以很容易的添加ActiveX控件。

API調(diào)用問(wèn)題

這是一個(gè)比較撓頭的問(wèn)題，由于.net下的資源相對(duì)有限，有時(shí)不得不利用調(diào)用非托管代碼的方式調(diào)用第三方庫(kù)。由于調(diào)試工具的缺乏，有時(shí)出了問(wèn)題不知問(wèn)題之所在。記得2003年在調(diào)用國(guó)外知名硬件廠家提供的動(dòng)態(tài)庫(kù)時(shí)，總是不能成功，折騰了近一個(gè)星期，在網(wǎng)上搜索了N多英文資料，最終發(fā)現(xiàn)是.net framework 1.0的bug。

也許有博友要問(wèn)，在.net平臺(tái)上利用C#開(kāi)發(fā)組態(tài)軟件到底給你們帶來(lái)哪些好處呢？經(jīng)過(guò)近幾年的實(shí)踐，可以說(shuō)好處是大大的，下面就我自己的感覺(jué)列出幾條，同時(shí)也是針對(duì)微軟當(dāng)年的承諾（也就是.net吸引我的地方）看微軟兌現(xiàn)了哪些。

內(nèi)存垃圾回收不再發(fā)生內(nèi)存泄漏

這一點(diǎn)應(yīng)該是部分做到。我們知道，用VC編寫(xiě)win32程序最頭疼的就是內(nèi)存泄漏問(wèn)題，在家里測(cè)試不到而在用戶那里被頻繁調(diào)用的內(nèi)存泄漏代碼會(huì)造成內(nèi)存的不斷上漲。這也是過(guò)去許多用戶抱怨機(jī)器頻繁死機(jī)的主要原因。

感謝微軟，.net的垃圾回收機(jī)制將程序員從這種緊張繁重的工作中解脫出來(lái)。至今為止，易控的用戶（包括那些每天24小時(shí)不停機(jī)的鋼廠用戶）還從未報(bào)過(guò)運(yùn)行系統(tǒng)死機(jī)的問(wèn)題。

說(shuō)它部分做到是因?yàn)橛行┐a，主要是GDI+相關(guān)代碼還需要手工釋放資源句柄。

.net程序可以跨平臺(tái)運(yùn)行

從理論上講，.net程序運(yùn)行在.net framework平臺(tái)上，與操作系統(tǒng)無(wú)關(guān)。但事實(shí)上這一點(diǎn)可能要落空了，雖說(shuō)有novell開(kāi)發(fā)的mono提供Linux平臺(tái)上的.net framwork，但一來(lái)mono的開(kāi)發(fā)遠(yuǎn)遠(yuǎn)滯后與.net framework的更新，二來(lái)程序難免有部分地方需要調(diào)用底層API。設(shè)想程序可以無(wú)縫移植到Linux上目前不太現(xiàn)實(shí)。

程序在網(wǎng)絡(luò)上運(yùn)行如同在單機(jī)上運(yùn)行

這一點(diǎn)微軟做的比較好，無(wú)論是早期的.net Remoting還是現(xiàn)在的WCF，訪問(wèn)遠(yuǎn)程對(duì)象幾乎同訪問(wèn)本機(jī)對(duì)象一樣簡(jiǎn)單，只需添加幾條指令即可。這也為開(kāi)發(fā)基于網(wǎng)絡(luò)的組態(tài)軟件提供了強(qiáng)大的武器。尤其是WCF，支持多種通道，并可以方便地更換通道，感興趣者可以參考WCF的教程。

桌面應(yīng)用程序和Web應(yīng)用程序采用同一套代碼

這點(diǎn)直到.net framework 3.0才得以實(shí)現(xiàn)，并且Web程序仍然存在訪問(wèn)安全機(jī)制的問(wèn)題。但無(wú)論如何對(duì)組態(tài)軟件的開(kāi)發(fā)者來(lái)講都是一個(gè)福音，再也無(wú)需為了支持Web發(fā)布重新編寫(xiě)大量的代碼了，不過(guò)前提條件是將你的圖形改成WPF圖形元件，從WPF提供的強(qiáng)大功能來(lái)看還是值得的。

豐富的圖形界面

凡是用過(guò)易控的用戶無(wú)不對(duì)其精美的畫(huà)面贊不絕口，這是利用.net對(duì)GDI+的支持實(shí)現(xiàn)的，目前的WPF還提供了對(duì)2D和3D動(dòng)畫(huà)的支持，這是通過(guò)封裝DirectX實(shí)現(xiàn)的。想像一下，編寫(xiě)一個(gè)支持2D和3D圖形動(dòng)畫(huà)的組態(tài)軟件是不是很酷？

 .net平臺(tái)還有許多引人入勝的地方，在此不一一列舉。事實(shí)上，.net對(duì)我影響最大是其以xml語(yǔ)言描述配置的設(shè)計(jì)，這使得我們的架構(gòu)具有高度的靈活性和可擴(kuò)展性。基于服務(wù)的思想使得我們的模塊可以靈活的部署在網(wǎng)絡(luò)上。此外，除了C#語(yǔ)言的其他優(yōu)點(diǎn)外，我認(rèn)為C#是一款真正面向?qū)ο蟮恼Z(yǔ)言，你認(rèn)為如何呢？

生活不易，碼農(nóng)辛苦
如果您覺(jué)得本網(wǎng)站對(duì)您的學(xué)習(xí)有所幫助,可以手機(jī)掃描二維碼進(jìn)行捐贈(zèng)