（2）從實際項目談起，基於MEF的插件框架之整體設計

時間 2019-11-13

標籤實際項目談起基於 mef 插件框架整體設計简体版

原文原文鏈接

文章版權由做者李曉暉和博客園共有，若轉載請於明顯處標明出處：http://www.cnblogs.com/naaoveGIS/。java

1.MEF框架簡介

MEF的全稱是Managed Extensibility Framework（MEF），其是.net4.0的組成部分，在3.5上也可使用。熟悉java中的spring框架的人，對這個框架中涉及的幾個概念應該會比較容易理解。spring

這裏我先把我兩年多前的一個完整的利用MEF搭建的插件式系統中涉及到的MEF框架裏的幾個基本概念大體描述下。服務器

1.1 依賴注入（export、import）

MEF框架中提供 import和export功能，即注入和導出。Spring中有依賴注入這個概念，這裏的這個概念也是大同小異，即將某個對象實例化後，注入到依賴這個實例的對象中，如此能夠下降類之間的耦合。一樣，與spring中的注入相似，MEF也有延遲注入這個概念，普通的依賴注入在整個程序開始運行時便進行了注入，而這種延遲注入能夠作到只有當對象須要被使用時才進行注入。微信

1.2約定（Contracts）

約定是與依賴注入相輔相成的。依賴注入最大的好處就是類與類之間解耦，可是如何知道究竟是將一個類注入到另一個類中呢，這裏就須要約定這個概念了。既須要注入的類並不用直接引用對方的類，而是二者經過一個共同的接口（也能夠是類等其餘），此接口即爲約定，從而進行導出和注入。app

1.3 目錄和組件容器（catalog、compositionContainer）

咱們用spring時，針對不一樣的應用，咱們只須要啓動applicationContext或者WebApplicationContext將配置加載到IOC容器中，根據XML配置或者註記即可以實現類的依賴注入。在MEF框架中，這種IOC容器須要代碼來進行實現，而且配置通常經過註記的方式。框架

這裏涉及到兩個概念，分別是catalog和compositionContainer。catalog中將全部須要組裝到IOC容器中的類集中到一塊兒，而後再將catalog放入到componentContainer中，這樣咱們的IOC容器便擁有了全部的須要進行控制的類。可是僅僅放入後，也並不能讓容器進行自動的依賴注入，它還須要咱們進行ComposeExportedValue和SatisfyImportsOnce這樣的操做，才能真正的完成依賴注入的全過程。工具

1.4 MEF框架圖

2.系統設計

我這裏先把兩年前的那個項目的內容大體描述下。該項目爲一個影像處理全自動化的項目，分爲影像的自動化接收，利用Platform進行並行化預處理，而後再利用此平臺對影像進行冰凌、乾旱、洪澇的分析處理，最後生成產品後發佈和入庫。當時是由幾個大學和一個單位一塊兒合做完成的，哪幾個大學就不說了。我只是這些衆多參與人中的一個，不過我不是像他們作遙感用envi的DLL語言處理影像的，也不是他們用Platform作並行計算的，也不是那些後臺作產品發佈和入庫的。我作的主要是下面這個需求。.net

2.1需求

（1）將天天接受的原始影像展示在前臺，儘可能以合理的美觀的方式展示。插件

（2）提供影像的查詢功能，包括時間空間等查詢。設計

（3）提供影像的下載功能。

（4）提供日誌的查詢功能。

（5）提供對服務器的監聽功能。

（6）將手動處理完的成果進行管理和展現。

（7）提供對手動處理完的數據進行元數據註冊。

（8）能將自動化中的各個模塊提煉成手動也能輔助進行的模塊，而且能夠集成到系統中。

2.2需求分析

看了需求後，我第一個感受就是這個系統得作出插件式系統，最後我選定了MEF。既然決定了要作插件式系統，那麼就得把需求分一個類，及哪些是宿主程序自己有的，哪些是該作成插件。顯而易見，需求中的（1）到（6）均可以作在宿主程序中。而（7）和（8）的話，都是單獨的插件模塊，由於這（7）和（8）的功能都是提取自自動化流程中的，由各個不一樣的人員完成，我這裏只須要提供他們統一的接口以及須要的調用方式就能夠由他們自身作成插件了。並且之後可能會將更多的自動化流程提取出來，都作成插件後，方便擴展。