C#通訊框架知識點有哪些

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

1.1    通訊的本質

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

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

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

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

    現在基本都是面向對象開發方式，new出來一個對象，把對象的屬性賦值后，直接把對象傳給接口函數完成發送數據。這種操作方式使開發者更多的關注業務層面，從而掩蓋了很多技術細節，例如：序列化、協議、編碼、字節流的操作等等。

    但是，SuperIO保持對底層字節流（byte[]）的操作，更多的關注通訊框架、數據協議、數據緩存、數據處理流程、設備驅動、插件、二次開發等方面。因為在物聯網時代，將會面對很多數據源，包括：各種傳感器、手機、PC端、智能硬件、傳統嵌入式設備等等，協議眾多，并且很難統一，所以最直接的操作數據就是字節流（byte[]）。另外，很早以前傳輸技術不發達（300波特率），同時受寄存器的存儲限制，為了減小數據量，1個字節的8位要表示8種狀態類型。

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

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

1.2    框架簡介

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

     隨著市場和公司發展的需要，需要整合、重構軟件系統以適應環境、硬件的不斷變化，降低人力、運維成本，釋放勞動力。

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

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

     從軟件工程角度出發，在設計層面要采用獨特的軟件構架和設計模式來達到我們預期的目標：

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

• n  增加組裝的封裝性。

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

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

• n  軟件具有靈活的可擴展性。

• n  軟件產品的擴展和開發實現標準化。

• n  軟件產品具有面向不同應用層面的適應性和易移植性。

    為了實現這些要求，在設計層面上，越來越多的軟件產品開始采用應用框架的思想進行軟件結構設計。應用框架已經是一個被廣泛使用的術語，它成為軟件開中一種非常實用并且常用的設計、開發規范。

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

    在架構師眼里，代碼都是需要設計的，都是有框架的。

1.3    解決現實問題

    在工業領域，經常遇到軟硬件之間的數據交互，并且面臨著復雜的現場環境：

（1）復雜的、多樣的通訊協議。有標準的協議，例如：Modbus等，也有很多根據標準協議修改的協議格式、以及自定義協議格式，并且千差萬別。對于不好的軟件架構，疲于應對，增加設備或協議要對整個軟件進行梳理，往往在此過程中出現新的問題或BUG。

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

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

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

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

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

1.4    應用場景

    作為一個框架平臺，在形成產品后要定位它的應用場景，在設計框架之前要有清晰的認識，并在設計過程中不斷強化應用目標。

    在產品應用方面，框架平臺可能要部署在PC機上，與眾多硬件、傳感器進行數據交互，并在本地進行數據存儲。

     在項目應用方面，框架平臺可能部署在服務器端，與客戶端（PC機、硬件、傳感器等）進行數據交互，并存儲到數據中。

     既然框架平臺在PC機上和服務端都可能應用，那么框架與框架之間也有數據交互的可能性。

     所以，框架平臺的交互場景包括兩方面：第一、與硬件產品交互。第二、與軟件產品交互。基本這兩方面考慮：

1）框架平臺應用在PC機上

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

采集硬件設備的數據信息。同時，通訊平臺與服務器端的軟件進行交互，負責上傳數據信息，以及接收控制命令等。

2）框架平臺應用在服務器端上

終端設備以3G/4G、有線專網、衛星等與通訊平臺連接，進行數據交互，終

端設備包括：PC機、移動終端（手機）、監測設備和傳感器等。

    基于以上考慮，框架平臺的應用場景結構圖如下：

1.5    框架應用特點

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

• n  快速構建通訊數據采集平臺軟件的宿主程序

• n  快速構建設備驅動，以及相關的協議驅動、命令緩沖、自定義參數和實時數據屬性等

• n  快速二次開發圖形顯示、數據輸出、服務驅動，并以插件的形式進行掛載。

• n  一個設備驅動，同時支持串口（COM）和網絡（TCP Server/Tcp Client）通訊機制，可以自由切換

• n  內置協議驅動，可以把第三方協議轉換成自定義的協議，協議的本質是對字節流的操作。

• n  內置設備命令緩沖器，可以設置命令發送的優先級別，保證命令的快速響應。

• n  以服務驅動插件的方式對OPC服務、4-20mA輸出、LED大屏顯示、短信服務等進行二次開發。

• n  快速開發、運行穩定、擴展性強大

• n  適用工業上位機軟件，以及系統集成中采集遠程設備數據

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

1.6    框架設計特點

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

穩定性

      對于一個實時數據采集框架來說，首要的設計特點就是穩定性，這是其他一切特點的前提。不能出現異常后軟件無故退出的現象、不能出現關閉軟件后進程無法退出的現象、不能出現無法響應數據的現象、不能出現無法處理數據的現象等等。

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

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

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

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

     穩定性是軟件運行的最直接反應，是所有實時性框架設計最主要考慮的因素，也是最難達到的。

擴展性

      用戶可能比設計者更關心穩定性，但是用戶不僅僅滿足于穩定性，還會提出各種新需求，更多的體現在功能方面。如果擴展性不好，對于開發者來說是萬丈深淵。

      所以，可擴展性是應用框架最顯著的特征之一，它意味著應用框架的功能具有生長能力。沒有擴展能力的應用框架毫無使用價值和意義，因為框架本身就是為了提供一個統一的上下文環境給具體的應用使用。應用框架的可擴展性使我們能夠基于一個平臺實現不同的功能，滿足不同的應用需求，有些需求是框架本身就支持的。

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

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

      模塊化，并不是把每個功能都編譯成一個DLL程序集就可以稱之為模塊化，一個程序集內部也可以模塊化。從框架層面在邏輯上橫向、縱向對模塊和層次進行劃分，以降低模塊之間的耦合度，不會因為一個模塊的變化而影響其他模塊，劃分模塊時保證模塊之間輸入輸出的統一性。

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

       可維護性，根據業務需求變化能夠方便進行改變的能力，也是擴展性的落腳點。保證我們盡量少修改代碼完成需求而又不影響軟件的整體運行。

性能

     性能是軟件運行效率的重要指標，是對軟件運行極限的考驗。例如，不管掛載多少設備驅動，用戶要求1秒鐘要讀取一次所有設備的數據，如果實現不了，用戶說對不起，我們不能簽合同。

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

     當然，對于性能來講，軟件只是一個方面，更多的還涉及到網絡結構、服務器部署等方面，是一項綜合性的結構。

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

1.7    插件式應用框架

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

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

     Visual Studio IDE、Elipse等都是插件式的開發工具，并實現了很強大的插件機制，也促使這些軟件變的越來越強大。

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

• n  可以在無需對程序進行重新編譯和發布的條件下擴展程序的功能。

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

• n  在一個程序的業務邏輯不斷發生改變、新的規則頻頻加入時能夠靈活適應。

    實現插件機制一般有3種技術：基于動態連接庫DLL的插件、基于組件對象模型COM的插件、以及基于.NET反射技術的插件。

    SuperIO是使用反射技術實現的插件機制，在后面的章節中進行詳細介紹。

1.8    開發環境

開發語言

使用C#開發的SuperIO框架，當然使用其他語言也可以實現，例如：JAVA。

開發工具

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

支持框架

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

編譯環境

使用X86平臺對項目進行編譯，如果開發插件也需要用X86平臺進行編譯，主要考慮到32位和64位操作系統的通用性。如下圖：

開發環境：

一開始在Windows xp sp3操作系統下進行開發，后來升級到Windows 8/8.1。

1.9    第三方組件

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

    使用PCOMM.DLL對串口通道進行操作，沒有使用微軟自帶的SerialPort組件，因為這個組件與一些工業串口卡不兼容，請參見：SerialPort操作PCI-1621D多串口卡，出現異常"參數不正確"

    OPC服務端使用的是OPC基金會的WtOPCSvr.dll組件，但是這個需要正版授權。OPC客戶端使用的是OPCDAAuto.dll組件。可以在http://pan.baidu.com/s/1pJ7lZWf下載SuperIO_Demo.rar事例代碼，里邊有完整的OPC服務端和客戶端的代碼。

到此，關于“C#通訊框架知識點有哪些”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續學習更多相關知識，請繼續關注億速云網站，小編會繼續努力為大家帶來更多實用的文章！