C#框架的總體設計知識點有哪些

本篇內容介紹了“C#框架的總體設計知識點有哪些”的有關知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠學有所成！

2.1    宿主程序設計

    作為插件式應用框架，要有一個宿主程序來承載、加載插件，為插件、驅動提供可運行的環境，使宿主程序與插件無縫對接。宿主程序與插件的關系是水和魚的關系，有水沒魚，水就失去了價值；有魚沒水，魚就會死去。從關系的角度來分析，開發框架的目的是什么？是與其他事物發生關系，包括：開發者、二次開發者、應用者、插件、甚至其他軟件或組件等。發生的關系越多、相處越融洽，證明這個框架的價值越高。所以說，一個好的框架平臺，不僅體現了開發者的技術，同時反應了開發者的情商。

    SuperIO框架使用NET反射技術開發插件管理機制，在本章中不詳細介紹具體的技術細節，在《第8章 插件引擎設計》中再進行詳細的介紹技術應用。

    那么一個框架的宿主程序應該怎么樣去設計呢？或是說從哪些方面去考慮設計問題？在開發SuperIO框架的時候，一直在思考這個問題。首先，這個問題不應該從技術角度去考慮，而應該從人的角度去考慮如何做，應用者的角度、二次開發者的角度來規劃宿主程序。

    從應用角度來分析，宿主程序應該包括：用戶管理、設備驅動管理、設備狀態監視方式、自定義UI插件顯示方式、自定義輸出數據插件操作方式、服務插件的服務方式、軟件運行的監視方式、串口IO通道監視方式、網絡IO通道監視方式等等。這些是我們從大的方向規劃的，還需要再進一步細化，指引我們的開發工作。

    用戶管理，要支持多用戶以及用戶權限分配。針對實時數據采集框架，面對現場應用的時候，肯定會涉及到兩個角色：使用人員、工程師人員。針對使用人員的權限定位：可以查看參數和數據信息。針對工程師人員的權限定位：不僅擁有使用人員的權限，還可以修改參數。用戶管理的菜單，如下圖：

     設備驅動管理，設備驅動（插件）是通過接口、抽象類設計的框架核心部分之一，可以把二次開發好的設備插件加載到框架中運行，完成數據采集、校驗、解析、處理等相關操作，以及進行命令、數據的交互。同時，設備驅動管理還應該具體刪除相關的設備插件的功能。增加設備插件，如下圖：

     設備狀態監視方式，我們可以把它稱為“設備運行器”，它并不是對不同類型設備驅動的所有參數、屬性等數據進行簡單顯示，而是對設備通用參數、屬性、實時狀態等數據進行顯示、監視，例如：設備ID、設備名稱、地址、通訊類型、IO參數、IO狀態、通訊狀態、設備狀態、報警狀態、設備類型和編號等。如下圖：

     自定義UI插件顯示方式，二次開發者在規范的接口基礎上開發數據顯示方式，掛載到框架的配置文件中，當用戶單擊某一個顯示視圖的時候，以Tab Form的形式顯示，并且可以單擊按鈕進行關閉，如下圖：

     自定義輸出數據插件操作方式，這種輸出數據的是對實時數據的導出，更多的是以事務性的服務存在，可以把一類的設備數據輸出成多種數據格式。輸出數據插件可以通過配置文件進行加載，只要設備驅動有數據更新，就把數據通過接口傳遞給輸出數據插件，進行輸出操作。不在配置文件中配置插件信息，則程序不進行加載，不進行輸出操作。所以，這種事務性的服務不需要界面來完成，可以在宿主程序啟動時通過代碼來完成。

     服務插件的服務方式，這種服務是長期運行的事務性任務，所以更復雜一些。有些服務需要隨宿主程序啟動而自動運行，有些服務需要人工手動啟動才運行。在宿主程序啟動的時候要把服務的信息加載到菜單上，菜單里顯示的這些服務可能有些已經啟動了，有些需要通過單擊操作，顯示窗體并填寫必要的信息后才可能啟動。所以，宿主程序與服務插件不是單向交互，而是雙向數據、事件交互。例如：把設備的數據采集上來、處理之后，要把數據上傳到服務中心或其他區域，就可以開發一個插件來完成這項任務，如下圖：

     軟件運行的監視方式，這是一種實時日志監視器，可以監視框架運行情況、以及設備的運行情況。把異常的信息可以友好的顯示出來，把異常的詳細信息保存到日志文件。我們可以把它稱為“運行監測器”，對于實時數據采集框架的運行是很有幫助的。如下圖：

     串口IO通道監視方式，當某一個設備驅動以串口方式通訊時，當串口參數動態發生改變時會在串口監視器反映當前串口IO狀態，例如：增加串口、刪除串口、串口號和波特率的改變等。如下圖：

     網絡IO通道監視方式，相對好設計一些，只需要對Socket實例的連接和斷開進行事件反映，Socket實例有效時把信息增加到網絡監視器中，Socket實例無效時，并釋放了相關資源后，從網絡監視器刪除相關信息。如下圖：

      基于以上的分析，我們需要構建一個完整的宿主程序，必要的功能要有，但是這個程序不一定很復雜，因為有些功能、響應、屬性、數據等可以放到設備插件中完成，在《第3章   設備驅動的設計》中詳細介紹設計情況。構建的宿主程序，如下圖：

     如果光有了宿主程序，那么還沒有分析全面。還需要以二次開發者的角度分析宿主程序是否能夠與二次開發者保持良好的關系。這里涉及到宿主程序存在的形式問題，宿主程序作為SuperIO框架的一部分，是一個整體的組件。希望二次開發者繼承宿主程序就可以快速構建一個自己的主程序，可以在此基礎上擴展功能，這樣的話，需要把宿主程序的關鍵控件的訪問權限設置成protected。另外，宿主程序還需要一個配置文件，把二次開發者關心的參數可設置，例如：標題、版本號、公司名稱等。

    經過上述的過程，我們就對宿主程序有一個清晰認識和規劃。界面的骨架已經搭建出來，在后期的開發過程序中從細節著手，逐步實現這些功能。但是，這樣一個簡單的界面需要很多類、模塊等支撐。以后章節會對每個模塊進行詳細設計說明。                                

2.2    通訊機制設計

    對于實時數據采集框架，通訊部分始終是軟件的核心，要求高實時性、高穩定性。軟件框架決定了軟件運行的穩定性，以及以后的擴展性，所以需要對通訊機制、控制方式進行良好的設計。

    在《1.通訊框架介紹》中的已經對應用場景進行了介紹，所以決定了軟件框架在通訊方面的應用有兩種方式：主動請求和被動接收。

    主動請求方式又可以稱之為呼叫應答方式或主從方式。也就是說，主動權在軟件框架端，只有軟件框架主動發送請求命令，從機（硬件設備、傳感器等）接收到命令后并且檢驗數據的完整性，以及確定是否發給自己的命令，校驗成功后，返回指定的數據信息，完成一次完整的鏈路通訊過程。呼叫應答通訊方式，如下圖：

   被動接收方式是軟件框架實時監測IO通道，只要有數據信息就會提取出來，進行數據校驗，檢驗成功后，分析、處理、保存數據信息。例如設備、傳感器等定時發送狀態數據。這種通訊方式，如下圖：

    在復雜的應用場景中，這兩種通訊方式都有可能存在，此類情況一般是采用以太網鏈路進行通訊。針對只有外接串口的設備可以通過以太網轉換模塊來接入。

2.1.1    串口通訊機制

由于串口通訊的特性限制，避免多個硬件設備連接到串口總線出現數據混亂

現象，一般采用輪詢模式的呼叫應答通訊機制。

2.1.1.1     輪詢模式

當有多個設備連接到通訊平臺時，通訊平臺會輪詢調度設備進行通訊任務。某一時刻只能有一個設備發送請求命令、等待接收返回數據，這個設備完成發送、接收（如果遇到超時情況，則自動返回）后，下一個設備才進行通訊任務，依次輪詢設備。如下圖：

2.2.2    網絡通訊機制

   輪詢通訊機制是保證數據有序的發送、接收，避免并發數據在串口總線上出現混亂，但是這種通訊機制是以降低性能為代價的，適用于串口通訊，在以太網通訊中顯然無法充分利用網絡通訊的優勢。以太網是獨立信道、可以全雙工通訊。為了充分發揮以太網的優勢，在輪詢通訊機制的基礎上增加了并發通訊模式、自控通訊模式。一是為了提高通訊的性能，二是為了二次開發有更多自主控制權。

2.2.2.1     輪詢模式

   以太網輪詢通訊模式與串口通訊模式一致，如下圖：

2.2.2.2    并發模式

     并發通訊模式是集中發送所有設備的請求指令，現在SuperIO框架是采用循環同步方式發送請求命令。還有進一步提高的機會，采用并行異步方式集中發送請求命令。硬件設備接收到指令后進行校驗，校驗成功后返回對應指令的數據，通訊平臺異步監聽到數據信息后，進行接收操作，然后再進行數據的分發、處理等。如下圖：

2.2.2.3    自控模式

     自控通訊模式與并發通訊模式類似，區別在于發送指令操作交給設備驅動本身進行控制，或者說交給二次開發者，二次開發者可以通過時鐘定時用事件驅動的方式發送指令數據。硬件設備接收到指令后進行校驗，校驗成功后返回對應指令的數據，通訊平臺異步監聽到數據信息后，進行接收操作，然后再進行數據的分發、處理等。

      自控通訊模式可以為二次開發者提供精確的定時請求實時數據機制，使通訊機制更靈活、自主。如下圖：

      并發模式和自控模式都可被動接收數據，應用場景更加靈活，使軟件框架和硬件設備的開發過工作更自由。

2.3   層次示意圖

2.4    模型對象示意圖

“C#框架的總體設計知識點有哪些”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業相關的知識可以關注億速云網站，小編將為大家輸出更多高質量的實用文章！