C#通訊框架知識點(diǎn)有哪些

這篇文章主要介紹“C#通訊框架知識點(diǎn)有哪些”，在日常操作中，相信很多人在C#通訊框架知識點(diǎn)有哪些問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”C#通訊框架知識點(diǎn)有哪些”的疑惑有所幫助！接下來，請跟著小編一起來學(xué)習(xí)吧！

1.1    通訊的本質(zhì)

     通訊就是信息的傳遞，信息傳遞又分為：單向信息傳遞和雙向信息傳遞。用喇叭進(jìn)行廣播是單向信息傳遞，打電話是雙向信息傳遞。

     單向信息傳遞相對較為簡單，只需要向信息接收者實(shí)時發(fā)送數(shù)據(jù)，而不用管信息是否到達(dá)，以及到達(dá)后是否進(jìn)行了處理。這種信息傳遞方式適用于對數(shù)據(jù)完整性要求不高的應(yīng)用場景，例如：采集溫度傳感器的數(shù)據(jù)。但是，如果數(shù)據(jù)源或是傳感器比較多的話，要考慮到并發(fā)量的問題，隨著互聯(lián)網(wǎng)技術(shù)的發(fā)展，并發(fā)問題是可以很好的解決。

     雙向信息傳遞相對較為復(fù)雜，不僅涉及到發(fā)送數(shù)據(jù)的問題，還涉及到信息握手、數(shù)據(jù)補(bǔ)傳等一系列交互問題。如果把雙向信息傳遞非要分成客戶端和服務(wù)端的話，還涉及到是哪一方先發(fā)起信息傳遞，客戶端主動向服務(wù)端發(fā)送數(shù)據(jù)，服務(wù)端接收到數(shù)據(jù)后進(jìn)行處理；但是，有時候服務(wù)端不希望接收到客戶端的數(shù)據(jù)，只有在服務(wù)端向客戶端發(fā)送請求命令后，客戶端根據(jù)命令才可以返回相應(yīng)的數(shù)據(jù)。在與硬件進(jìn)行雙向通訊的時候，還涉及到載波通道是半雙工和全雙工的問題，半雙工是同一時刻在通道上只能A向B或B向A發(fā)送數(shù)據(jù)，只能單向數(shù)據(jù)傳輸；全雙工是A向B發(fā)送數(shù)據(jù)，同時B向A也可以發(fā)送數(shù)據(jù)，發(fā)送和接收數(shù)據(jù)兩者可以同步進(jìn)行。這種信息傳遞方式適用于對數(shù)據(jù)完全性要求比較高的應(yīng)用場景。

    不管是單向信息傳遞，還是雙向信息傳遞，都涉及傳輸協(xié)議、編碼方式和數(shù)據(jù)校驗(yàn)。傳輸協(xié)議是能夠封裝和解析并且能夠相互理解的數(shù)據(jù)格式，它是一種數(shù)據(jù)規(guī)約方式，可以使用標(biāo)準(zhǔn)的協(xié)議方式，例如：Modbus、XMPP、AMQP、MQTT等，也可以使用自定義協(xié)議；有了傳輸協(xié)議后，在傳輸過程中還涉及到編碼方式，例如：GBK、UTF、ASCII，有可能在編碼的基礎(chǔ)上還要進(jìn)行加密，以保證數(shù)據(jù)的安全性；為了數(shù)據(jù)包完全性、可解析性，還要增加對數(shù)據(jù)的校驗(yàn)，一般采用較多的校驗(yàn)方式為CRC。傳輸協(xié)議、編碼方式和數(shù)據(jù)校驗(yàn)的目的只有一個：防止數(shù)據(jù)在傳輸過程中受到干擾，或被惡意篡改，給數(shù)據(jù)處理造成意想不到的后果。打個比喻，一個中國人說普通話，一個外國人說美式英文，語法不一樣，編碼格式不一樣，結(jié)果造成說話聽不懂、文字看不懂，如果誤認(rèn)為是在罵人，有可能還要打一架。

    現(xiàn)在基本都是面向?qū)ο箝_發(fā)方式，new出來一個對象，把對象的屬性賦值后，直接把對象傳給接口函數(shù)完成發(fā)送數(shù)據(jù)。這種操作方式使開發(fā)者更多的關(guān)注業(yè)務(wù)層面，從而掩蓋了很多技術(shù)細(xì)節(jié)，例如：序列化、協(xié)議、編碼、字節(jié)流的操作等等。

    但是，SuperIO保持對底層字節(jié)流（byte[]）的操作，更多的關(guān)注通訊框架、數(shù)據(jù)協(xié)議、數(shù)據(jù)緩存、數(shù)據(jù)處理流程、設(shè)備驅(qū)動、插件、二次開發(fā)等方面。因?yàn)樵谖锫?lián)網(wǎng)時代，將會面對很多數(shù)據(jù)源，包括：各種傳感器、手機(jī)、PC端、智能硬件、傳統(tǒng)嵌入式設(shè)備等等，協(xié)議眾多，并且很難統(tǒng)一，所以最直接的操作數(shù)據(jù)就是字節(jié)流（byte[]）。另外，很早以前傳輸技術(shù)不發(fā)達(dá)（300波特率），同時受寄存器的存儲限制，為了減小數(shù)據(jù)量，1個字節(jié)的8位要表示8種狀態(tài)類型。

    在物聯(lián)網(wǎng)時代，將面臨各種通訊情況，例如：一個串口通道，一對一、一對多的方式通訊；一個網(wǎng)絡(luò)IP通道，一對一、一對多的通訊。所以，沒有一個好的框架支撐是無法滿足通用性的要求。

     有人問題串口通訊、網(wǎng)絡(luò)通訊怎么做，有人回答這些很容易，但是要把上述問題以及其他問題都考慮周全的話就是一個復(fù)雜的問題，并且有些問題不是很好解決。

1.2    框架簡介

      如果一個公司的硬件產(chǎn)品眾多，協(xié)議又各不相同，每一個硬件產(chǎn)品都對應(yīng)一套上位機(jī)軟件，需要專人維護(hù)。而客戶的需求日益變化，造成維護(hù)成本較高，并且阻礙了公司的快速發(fā)展。另外，就算修改同類硬件產(chǎn)品的配套軟件，也可能造成新的BUG出現(xiàn)。

     隨著市場和公司發(fā)展的需要，需要整合、重構(gòu)軟件系統(tǒng)以適應(yīng)環(huán)境、硬件的不斷變化，降低人力、運(yùn)維成本，釋放勞動力。

     所以，對于發(fā)展到一定階段、或是一個成熟的公司必然要有軟件框架作為支撐，這是從業(yè)務(wù)角度考慮發(fā)展應(yīng)用框架的必然性。

     技術(shù)方面，框架是一個系統(tǒng)全部或部分的可復(fù)用設(shè)計，通常由一組接口、抽象類和類之間的協(xié)作組成。隨著信息化的發(fā)展，軟件產(chǎn)品的開發(fā)也越來越復(fù)雜化，解決問題的復(fù)雜度也在不斷的提高。IT界也在尋找多種方法，包括制定各種軟件開發(fā)標(biāo)準(zhǔn)和規(guī)范、開發(fā)更高級更有生產(chǎn)力的編程語言、開發(fā)更好的編譯器和運(yùn)行時以及不需要編譯的解釋性開發(fā)語言、開發(fā)功能強(qiáng)大以及更通用性的組件庫、探索適用不同應(yīng)用場景的設(shè)計模式等。

     從軟件工程角度出發(fā)，在設(shè)計層面要采用獨(dú)特的軟件構(gòu)架和設(shè)計模式來達(dá)到我們預(yù)期的目標(biāo)：

• n  盡量提高軟件的可重用性，避免不必要的重復(fù)編碼工作。

• n  增加組裝的封裝性。

• n  提高軟件的模塊化程度。

• n  不同功能模塊之間能夠無縫集成。

• n  軟件具有靈活的可擴(kuò)展性。

• n  軟件產(chǎn)品的擴(kuò)展和開發(fā)實(shí)現(xiàn)標(biāo)準(zhǔn)化。

• n  軟件產(chǎn)品具有面向不同應(yīng)用層面的適應(yīng)性和易移植性。

    為了實(shí)現(xiàn)這些要求，在設(shè)計層面上，越來越多的軟件產(chǎn)品開始采用應(yīng)用框架的思想進(jìn)行軟件結(jié)構(gòu)設(shè)計。應(yīng)用框架已經(jīng)是一個被廣泛使用的術(shù)語，它成為軟件開中一種非常實(shí)用并且常用的設(shè)計、開發(fā)規(guī)范。

    我們肯定見過很多自稱“框架”的軟件產(chǎn)品，也許有人會感覺不屑，有些代碼量很少的程序居然也稱自己是某種形式的應(yīng)用框架？事實(shí)上，應(yīng)用框架無關(guān)乎規(guī)模大小，就像房屋一樣，摩天大樓和民房都是房屋，只不過它們的規(guī)模和精巧度大小不一樣而已。

    在架構(gòu)師眼里，代碼都是需要設(shè)計的，都是有框架的。

1.3    解決現(xiàn)實(shí)問題

    在工業(yè)領(lǐng)域，經(jīng)常遇到軟硬件之間的數(shù)據(jù)交互，并且面臨著復(fù)雜的現(xiàn)場環(huán)境：

（1）復(fù)雜的、多樣的通訊協(xié)議。有標(biāo)準(zhǔn)的協(xié)議，例如：Modbus等，也有很多根據(jù)標(biāo)準(zhǔn)協(xié)議修改的協(xié)議格式、以及自定義協(xié)議格式，并且千差萬別。對于不好的軟件架構(gòu)，疲于應(yīng)對，增加設(shè)備或協(xié)議要對整個軟件進(jìn)行梳理，往往在此過程中出現(xiàn)新的問題或BUG。

（2）針對不同用戶對軟件界面或功能的要求有很大不同，使之滿足不同用戶的顯示要求，可以自定義數(shù)據(jù)顯示界面。

（3）在做集成項(xiàng)目的時候，輸入輸出數(shù)據(jù)的多樣性。首先，要集成其他廠家的設(shè)備，要求數(shù)據(jù)進(jìn)行接入。其次，還有很多是其他廠家要集成自己家的設(shè)備，就涉及的輸出數(shù)據(jù)的問題，數(shù)據(jù)格式要求也是千差萬別。  

（4）通訊鏈路的多種性，對于同一個設(shè)備可能要支持RS232/RS485/RS422、RJ45、3G/4G等通訊方式，所以對于一個設(shè)備要對應(yīng)多種通訊方式（串口和網(wǎng)絡(luò)），也給我們的開發(fā)造成很大的障礙。

（5）軟件各版本、以及軟件與硬件之間的兼容性很差，管理起來錯綜復(fù)雜。

   為了解決以上諸多問題，開發(fā)一個軟件框架，支持二次開發(fā)。在不對軟件框架改動的情況下，能夠很方便的接入設(shè)備、維護(hù)設(shè)備、集成設(shè)備、處理設(shè)備業(yè)務(wù)數(shù)據(jù)等。軟件框架相對穩(wěn)定，把容易變化的部分進(jìn)行靈活設(shè)計。

1.4    應(yīng)用場景

    作為一個框架平臺，在形成產(chǎn)品后要定位它的應(yīng)用場景，在設(shè)計框架之前要有清晰的認(rèn)識，并在設(shè)計過程中不斷強(qiáng)化應(yīng)用目標(biāo)。

    在產(chǎn)品應(yīng)用方面，框架平臺可能要部署在PC機(jī)上，與眾多硬件、傳感器進(jìn)行數(shù)據(jù)交互，并在本地進(jìn)行數(shù)據(jù)存儲。

     在項(xiàng)目應(yīng)用方面，框架平臺可能部署在服務(wù)器端，與客戶端（PC機(jī)、硬件、傳感器等）進(jìn)行數(shù)據(jù)交互，并存儲到數(shù)據(jù)中。

     既然框架平臺在PC機(jī)上和服務(wù)端都可能應(yīng)用，那么框架與框架之間也有數(shù)據(jù)交互的可能性。

     所以，框架平臺的交互場景包括兩方面：第一、與硬件產(chǎn)品交互。第二、與軟件產(chǎn)品交互?；具@兩方面考慮：

1）框架平臺應(yīng)用在PC機(jī)上

主要應(yīng)用在自動站的工控機(jī)上，通過RS485/RS232、RJ45、4-20mA等方式

采集硬件設(shè)備的數(shù)據(jù)信息。同時，通訊平臺與服務(wù)器端的軟件進(jìn)行交互，負(fù)責(zé)上傳數(shù)據(jù)信息，以及接收控制命令等。

2）框架平臺應(yīng)用在服務(wù)器端上

終端設(shè)備以3G/4G、有線專網(wǎng)、衛(wèi)星等與通訊平臺連接，進(jìn)行數(shù)據(jù)交互，終

端設(shè)備包括：PC機(jī)、移動終端（手機(jī)）、監(jiān)測設(shè)備和傳感器等。

    基于以上考慮，框架平臺的應(yīng)用場景結(jié)構(gòu)圖如下：

1.5    框架應(yīng)用特點(diǎn)

　　對于框架的特點(diǎn)，我們要有簡單、清晰的規(guī)劃，其中包括：功能層面、性能層面、應(yīng)用層面、運(yùn)行層面、二次開發(fā)層面等等 ，這些將強(qiáng)化我們在設(shè)計、開發(fā)過程的目標(biāo)。這些不僅要寫在紙上，更要記在腦子里。SuperIO在設(shè)計的時候，簡單的列出了它的特點(diǎn)，盡管有些特點(diǎn)是后來完善的，如下：

• n  快速構(gòu)建通訊數(shù)據(jù)采集平臺軟件的宿主程序

• n  快速構(gòu)建設(shè)備驅(qū)動，以及相關(guān)的協(xié)議驅(qū)動、命令緩沖、自定義參數(shù)和實(shí)時數(shù)據(jù)屬性等

• n  快速二次開發(fā)圖形顯示、數(shù)據(jù)輸出、服務(wù)驅(qū)動，并以插件的形式進(jìn)行掛載。

• n  一個設(shè)備驅(qū)動，同時支持串口（COM）和網(wǎng)絡(luò)（TCP Server/Tcp Client）通訊機(jī)制，可以自由切換

• n  內(nèi)置協(xié)議驅(qū)動，可以把第三方協(xié)議轉(zhuǎn)換成自定義的協(xié)議，協(xié)議的本質(zhì)是對字節(jié)流的操作。

• n  內(nèi)置設(shè)備命令緩沖器，可以設(shè)置命令發(fā)送的優(yōu)先級別，保證命令的快速響應(yīng)。

• n  以服務(wù)驅(qū)動插件的方式對OPC服務(wù)、4-20mA輸出、LED大屏顯示、短信服務(wù)等進(jìn)行二次開發(fā)。

• n  快速開發(fā)、運(yùn)行穩(wěn)定、擴(kuò)展性強(qiáng)大

• n  適用工業(yè)上位機(jī)軟件，以及系統(tǒng)集成中采集遠(yuǎn)程設(shè)備數(shù)據(jù)

• n  支持Windows XP/7/8/8.1、Windows Server 2003/2008/2012

1.6    框架設(shè)計特點(diǎn)

    有些書籍說了一大堆設(shè)計特點(diǎn)，有點(diǎn)讓人不知所云，沒見有層次感，我認(rèn)為對于此類框架的特點(diǎn)最重要的包括兩點(diǎn)：穩(wěn)定性、擴(kuò)展性、性能。

穩(wěn)定性

      對于一個實(shí)時數(shù)據(jù)采集框架來說，首要的設(shè)計特點(diǎn)就是穩(wěn)定性，這是其他一切特點(diǎn)的前提。不能出現(xiàn)異常后軟件無故退出的現(xiàn)象、不能出現(xiàn)關(guān)閉軟件后進(jìn)程無法退出的現(xiàn)象、不能出現(xiàn)無法響應(yīng)數(shù)據(jù)的現(xiàn)象、不能出現(xiàn)無法處理數(shù)據(jù)的現(xiàn)象等等。

     基于可能存在的這些潛在的問題，我們要考慮：容錯機(jī)制、模塊無縫對接、記錄日志等。

     容錯機(jī)制是所有軟件都有的一種機(jī)制，核心思想是對異常狀態(tài)的處理方法。對于操作一般性的功能，如果出現(xiàn)異常狀態(tài)，我們可能不需要過多的干預(yù)，只需要進(jìn)行日志記錄就可以了，對于再次操作同樣的功能可以驗(yàn)證異常狀態(tài)的可重復(fù)性，根據(jù)日志信息可以有針對性的進(jìn)行解決；對于事務(wù)性的任務(wù)，對異常狀態(tài)的處理會有多種選擇，可以簡單的記錄異常信息、可以銷毀當(dāng)前的資源，重新開始任務(wù)，直接任務(wù)成功、可以恢復(fù)到出現(xiàn)異常狀態(tài)的節(jié)點(diǎn)等，根據(jù)不同的場景，選擇處理的方式也不一樣。就相當(dāng)于，某人說錯話了，要進(jìn)行補(bǔ)救，那就要看當(dāng)時的環(huán)境和面對的人，如果是好朋友，這事就算過去了。

     模塊無縫對接要求我們對接口、抽象類以及類的模塊劃分、設(shè)計粒度有很好的把握，更多的體現(xiàn)在經(jīng)驗(yàn)方面。模塊之間是一個契約關(guān)系，如何履行契約會涉及到很多設(shè)計模式的選擇，所以說對設(shè)計模塊的把握程度直接影響軟件框架的成熟度。就好比兩個人對話，說話方式、語意都不能相互理解，就有可能話不投機(jī)半句多。

     記錄日志是所有軟件必須要有的特點(diǎn)，這為我們排查錯誤提供了很大的方便。日志記錄有很多開源的項(xiàng)目可以拿來直接使用，例如常用的Log4Net。但是，有時間研究這東西的時間，自己也能寫一個適用于自己的日志庫了。

     穩(wěn)定性是軟件運(yùn)行的最直接反應(yīng)，是所有實(shí)時性框架設(shè)計最主要考慮的因素，也是最難達(dá)到的。

擴(kuò)展性

      用戶可能比設(shè)計者更關(guān)心穩(wěn)定性，但是用戶不僅僅滿足于穩(wěn)定性，還會提出各種新需求，更多的體現(xiàn)在功能方面。如果擴(kuò)展性不好，對于開發(fā)者來說是萬丈深淵。

      所以，可擴(kuò)展性是應(yīng)用框架最顯著的特征之一，它意味著應(yīng)用框架的功能具有生長能力。沒有擴(kuò)展能力的應(yīng)用框架毫無使用價值和意義，因?yàn)榭蚣鼙旧砭褪菫榱颂峁┮粋€統(tǒng)一的上下文環(huán)境給具體的應(yīng)用使用。應(yīng)用框架的可擴(kuò)展性使我們能夠基于一個平臺實(shí)現(xiàn)不同的功能，滿足不同的應(yīng)用需求，有些需求是框架本身就支持的。

     框架的可擴(kuò)展性主要是通過繼承和聚合兩種方式實(shí)現(xiàn)的。繼承方式是指通過派生類繼承基類或接口，通過重用基類的功能并定義新的功能的方式實(shí)現(xiàn)功能擴(kuò)展；聚合方式是指調(diào)用不同的類型組合為一個新類型而擴(kuò)展出全新的功能。研究Framework框架源代碼，能夠深切感受到繼承和聚合的作用。

      如果單說擴(kuò)展性會讓人有些空洞，那么我們還要考慮模塊化、可重用性、可維護(hù)性等等。

      模塊化，并不是把每個功能都編譯成一個DLL程序集就可以稱之為模塊化，一個程序集內(nèi)部也可以模塊化。從框架層面在邏輯上橫向、縱向?qū)δK和層次進(jìn)行劃分，以降低模塊之間的耦合度，不會因?yàn)橐粋€模塊的變化而影響其他模塊，劃分模塊時保證模塊之間輸入輸出的統(tǒng)一性。

      可重用性，也可以稱為可復(fù)用性，是衡量代碼質(zhì)量的重要標(biāo)志之一。既然是框架設(shè)計其中一個目的就是提高效率，減少沒有必要的重復(fù)勞作，降低成本。一般來說，框架可重用可以是離散存在的函數(shù)、可以是封裝好的類庫、可以是封裝好的眾多類庫，以方便我們在類似功能、業(yè)務(wù)中使用。

       可維護(hù)性，根據(jù)業(yè)務(wù)需求變化能夠方便進(jìn)行改變的能力，也是擴(kuò)展性的落腳點(diǎn)。保證我們盡量少修改代碼完成需求而又不影響軟件的整體運(yùn)行。

性能

     性能是軟件運(yùn)行效率的重要指標(biāo)，是對軟件運(yùn)行極限的考驗(yàn)。例如，不管掛載多少設(shè)備驅(qū)動，用戶要求1秒鐘要讀取一次所有設(shè)備的數(shù)據(jù)，如果實(shí)現(xiàn)不了，用戶說對不起，我們不能簽合同。

     在互聯(lián)網(wǎng)行業(yè)對性能的要求更高、更全面，有很多指標(biāo)性的參數(shù)，例如：響應(yīng)時間、延遲時間、吞吐量、并發(fā)量、資源利用率等等，所以一般要對軟件、服務(wù)進(jìn)行壓力測試。在傳統(tǒng)行業(yè)方面也不防借鑒使用先進(jìn)的框架或第三方組件，例如：消息隊(duì)列框架（kafka、ActiveMq、RabbitMq、ZeroMq、EQueue），響應(yīng)式消息框架（Akka.net）、作業(yè)調(diào)度框架（Quartz.net）等等，這些能夠有助于提高軟件、系統(tǒng)的執(zhí)行效率和性能。

     當(dāng)然，對于性能來講，軟件只是一個方面，更多的還涉及到網(wǎng)絡(luò)結(jié)構(gòu)、服務(wù)器部署等方面，是一項(xiàng)綜合性的結(jié)構(gòu)。

     對于穩(wěn)定性、擴(kuò)展性、性能，它是一個整體的三個方面。相信大家都看過F1比賽，要求賽車在高速行駛過程中保持不翻車，高速行駛對輪胎磨損很嚴(yán)重，并且要求在很短的時間內(nèi)方便對輪胎的更換。

1.7    插件式應(yīng)用框架

     插件技術(shù)是在軟件的設(shè)計和開發(fā)過程中，將整個應(yīng)用程序劃分為宿主程序和插件對象兩部分，宿主程序能夠調(diào)用插件對象，插件對象能夠在宿主程序上實(shí)現(xiàn)自己的邏輯，而兩者的交互基于一種公共的通信契約。宿主程序可以獨(dú)立于插件對象存在，即使沒有任何插件對象，宿主程序的運(yùn)行也不受影響，因此，我們可以在避免改變宿主程序的情況下通過增減插件或修改插件的方式增加或調(diào)整功能。由于使用了插件技術(shù)的宿主程序具備了一個框架的本質(zhì)特征，因此可以將它看作是一種插件式框架。插件式框架能夠有效地降低功能對象與對象管理邏輯之間的耦合程度，并將耦合置于最優(yōu)的程度。

     對大部分計算機(jī)用戶和軟件開發(fā)者而言，插件式應(yīng)用框架其實(shí)算不上什么神秘的東西，事實(shí)上，幾乎每個人都曾使用過具有插件式功能的軟件產(chǎn)品。這些軟件有大有小，從操作簡單的諸如播放器軟件到復(fù)雜桀驁的各種專業(yè)應(yīng)用軟件，都或多或少采用過插件機(jī)制，只是對于最終用戶而言，由于常常滿足于使用一款成熟軟件，很少有人刻意去關(guān)注這些軟件使用的是什么樣的架構(gòu)體系。

     Visual Studio IDE、Elipse等都是插件式的開發(fā)工具，并實(shí)現(xiàn)了很強(qiáng)大的插件機(jī)制，也促使這些軟件變的越來越強(qiáng)大。

     一般而，一款軟件、一個框架使用插件機(jī)制的原因主要基于以下3點(diǎn)：

• n  可以在無需對程序進(jìn)行重新編譯和發(fā)布的條件下擴(kuò)展程序的功能。

• n  可以在不需要程序源代碼的環(huán)境下為程序增加新的功能。

• n  在一個程序的業(yè)務(wù)邏輯不斷發(fā)生改變、新的規(guī)則頻頻加入時能夠靈活適應(yīng)。

    實(shí)現(xiàn)插件機(jī)制一般有3種技術(shù)：基于動態(tài)連接庫DLL的插件、基于組件對象模型COM的插件、以及基于.NET反射技術(shù)的插件。

    SuperIO是使用反射技術(shù)實(shí)現(xiàn)的插件機(jī)制，在后面的章節(jié)中進(jìn)行詳細(xì)介紹。

1.8    開發(fā)環(huán)境

開發(fā)語言

使用C#開發(fā)的SuperIO框架，當(dāng)然使用其他語言也可以實(shí)現(xiàn)，例如：JAVA。

開發(fā)工具

一開始使用的是Visual Studio 2008工具進(jìn)行開發(fā)，后來升級到Visual Studio 2012，并對SuperIO進(jìn)行了重新編譯。

支持框架

一開始使用的是Framework 2.0框架進(jìn)行開發(fā)，后來升級到Framework 4.0，為了兼容較低版本的操作系統(tǒng)（Windows xp sp3），最高版本的框架只能使用Framework 4.0，再高版本的框架在Windows xp sp3下無法運(yùn)行。如下圖：

編譯環(huán)境

使用X86平臺對項(xiàng)目進(jìn)行編譯，如果開發(fā)插件也需要用X86平臺進(jìn)行編譯，主要考慮到32位和64位操作系統(tǒng)的通用性。如下圖：

開發(fā)環(huán)境：

一開始在Windows xp sp3操作系統(tǒng)下進(jìn)行開發(fā)，后來升級到Windows 8/8.1。

1.9    第三方組件

    使用Developer Express套件對框架的UI部分進(jìn)行布局，主要應(yīng)用在Menu、MdiTabForm、DockPanel這三個方面。

    使用PCOMM.DLL對串口通道進(jìn)行操作，沒有使用微軟自帶的SerialPort組件，因?yàn)檫@個組件與一些工業(yè)串口卡不兼容，請參見：SerialPort操作PCI-1621D多串口卡，出現(xiàn)異常"參數(shù)不正確"

    OPC服務(wù)端使用的是OPC基金會的WtOPCSvr.dll組件，但是這個需要正版授權(quán)。OPC客戶端使用的是OPCDAAuto.dll組件?？梢栽趆ttp://pan.baidu.com/s/1pJ7lZWf下載SuperIO_Demo.rar事例代碼，里邊有完整的OPC服務(wù)端和客戶端的代碼。

到此，關(guān)于“C#通訊框架知識點(diǎn)有哪些”的學(xué)習(xí)就結(jié)束了，希望能夠解決大家的疑惑。理論與實(shí)踐的搭配能更好的幫助大家學(xué)習(xí)，快去試試吧！若想繼續(xù)學(xué)習(xí)更多相關(guān)知識，請繼續(xù)關(guān)注億速云網(wǎng)站，小編會繼續(xù)努力為大家?guī)砀鄬?shí)用的文章！