http://www.cnblogs.com/mix-up/archive/2009/12/31/1636608.html
基於插件式的開發框架
基於插件式的開發框架: 源碼
2010-01-20 22:03:14| 分類： 插件|字號 訂閱
在此源代碼發佈後很多朋友提出了一些設計和技術方面的問題, 在本篇下方的評論處本人對其依依做了解答, 雖不能保證解答的正確性, 但強烈建議您去閱讀一下.
插件式以其身優勢廣爲開發者所喜愛，本人蔘與開發過的幾個項目都用到了插件式的概念。
最近幾天不是很忙， 抽空重新梳理了一下邏輯， 將業務部分剝離， 便有了此版的插件式的開發框架。
希望通過此代碼能與大家交流技術，探討問題，也希望大家提出寶貴意見。
- 概念
插件: 插件是可獨立完成某個或一系列功能的模塊.通常插件由宿主程序加載，不能獨立運行。
宿主: 宿主是承載插件運行的環境，爲插件提供基本服務。通常插件由宿主程序管理和控制。
插件式: 通常是由開發人員編寫宿主程序,並預先定義好系統提供基本服務接口和插件接口。然後由其他開發人員根據系統插件接口編寫插件功能。通常插件以一個獨立功能模塊的形式出現。對於宿主程序來說並不知道插件的具體功能，通常宿主啓動時檢索插件信息，並根據預定的插件接口裝載插件。
- 優勢
增強系統擴展性: 在系統發佈後可在不必重新編譯系統的前提下按需對系統功能進行擴充。
易維護及複用性: 插件通常爲獨立的功能模塊易於管理與維護，並可在多個業務系統中重用。
如果瞭解了以上這些信息那麼就不難閱讀這份源碼了。
聲明: 此代碼僅爲學習之用, 可自由轉載或使用, 但希望使用者儘量保留文件頭部信息以保證後續開發者能及時反饋.
項目結構
主要類型及接口
IHost 宿主接口PackageHost 插件宿主抽象類(此抽象類實現IHost接口,並提供插件管理功能. 定製基於業務的插件宿主應從此類繼承)IPackageServiceProvider 插件服務提供者接口(由此接口實現者提供插件服務)DictionaryServiceProviderAdapter IServiceProvider接口適配器(提供從Dictionary到IServiceProvider的轉換)IPackageProvider 插件提供者接口(由此接口實現者提供插件源)FilePackageProvider 文件插件提供者實現IPackageManager 插件管理器接口PackageManager 插件管理器實現IPackageController 插件控制器接口PackageController 插件控制器實現IPackage 插件接口(由此接口實現插件功能)
目錄結構
__
│
│ Addin.sln
│
├─Addin
│ │ Addin.csproj
│ │ IConfigurationInitialize.cs
│ │ IHost.cs
│ │ IPackage.cs
│ │ IPackageController.cs
│ │ IPackageProvider.cs
│ │ IPackageManager.cs
│ │ IPackageServiceProvider.cs
│ │ PackageController.cs
│ │ PackageControllerCollection.cs
│ │ PackageDescription.cs
│ │ PackageHost.cs
│ │ PackageManager.cs
│ │
│ ├─adapter
│ │ DictionaryServiceProviderAdapter.cs
│ │
│ ├─common
│ │ CancelEventArgs.cs
│ │ EventArgs.cs
│ │
│ ├─configuration
│ │ AddinSection.cs
│ │
│ ├─provider
│ │ FilePackageProvider.cs
│ │
│ └─utility
│ Guard.cs
│
├─Addin.HostDemo
│ │ Addin.HostDemo.csproj
│ │ Addin.HostDemo.csproj.user
│ │ FormHostManager.cs
│ │ HostForm.cs
│ │ HostForm.Designer.cs
│ │ HostForm.resx
│ │ Program.cs
│ │
│ ├─adapters
│ │ CommandBarItemCollectionAdapter.cs
│ │ CommandBarManagerAdapter.cs
│ │ CommandBarMenuAdapter.cs
│ │ StatusBarAdapter.cs
│ │
│ ├─packages
│ │ Addin.PackageDemo.dll
│ │ Addin.PackageDemo.dll.config
│ │
│ └─Properties
│ AssemblyInfo.cs
│
├─Addin.PackageDemo
│ │ Addin.PackageDemo.csproj
│ │ App.config
│ │ Form1.cs
│ │ Form1.Designer.cs
│ │ Form1.resx
│ │
│ └─Properties
│ AssemblyInfo.cs
│
└─Addin.Services
│ Addin.Services.csproj
│ ICommandBar.cs
│ ICommandBarCollection.cs
│ ICommandBarItem.cs
│ ICommandBarItemCollection.cs
│ ICommandBarManager.cs
│ ICommandBarMenu.cs
│ ICommandBarSeparator.cs
│ IContainer.cs
│ IStatusBar.cs
AssemblyInfo.cs
發表評論
@xiaosuo
嘿..你猜..
(源碼很重要,但理念更重要. 源碼請在貼子中查找..)
插件式的加密混淆是個問題，新舊插件非要一起混淆才能用。樓主真不考慮混淆問題麼？你的軟件全部開源？
@ganquan
你的軟件全部開源？
"開源"這詞實在不敢當,本貼意在探討設計而非代碼本身.個人覺得思想纔是難以跨越的障礙,至於代碼實在沒什麼技術含量.
插件式的加密混淆?
不好意思,我沒太理解這句,暫且我先認爲是代碼的加密.
上面的問題我已解釋了,就我個人而言不覺得這份代碼有多"珍貴".所以本人忽略代碼的加密.. 呵..
至於插件部分就取決於插件開發者了.
@Jack Fan
@瘋流成性
稍後我會抽空寫一些此框架開發過程中的小經驗.但初於本人表達能力較差,所以此過程可能會有點長,期待介時能與二位交流想法.
感謝二位的支持.
樓主，請教一個問題，你現在這個框加是 主程序一啓動，就加載程序，
那如果我要 按需加載怎麼做，（就是操作到這個模塊的時候才加載這個模塊），不然，模塊多了，我想主程序啓動的時候會很慢，而且還要加上權限的控制。
插件平臺對我來說也非常有吸引力，本人也開發了一個插件平臺，目前正在優化，一旦優化完成也將開源。
一個插件平臺至少需要考慮：（1）用戶如何開發、調試、部署插件？（2）插件平臺和插件的結構；（3）插件間的依賴與通訊；（4）插件的多版本問題和類加載機制；（5）插件的擴展；（6）按需加載。（附：此外，我們還需要考慮到WinForm、WPF、Web、RIA不同應用的插件平臺）
此外，還有很重要插件隔離以及安全性。不過，只是在.NET，要實現隔離就得使用AppDomain，而跨AppDomain會帶來很大性能損失，因此我暫時不考慮多個AppDomain。安全性比較重要但目前對我而言不是最緊急的。
對我來說，一個插件平臺最大的優點在於模塊化，模塊化就是從橫向來切割應用系統，從而使每個插件的開發都很簡單。
不知樓主是否考慮到這些問題，且如何解決的。
只要看lz用assembly.Loadfrom還是appdomain.Create 就知道這個插件的水平了。
公佈核心代碼吧。
說些個人感受的空話，插件技術和插件框架核心在於模塊化/組件化，模塊化核心在於高內聚、低耦合，插件框架是模塊化設計到一定階段的必然且必須的產物，插件框架做的更好就一定要參考osgi規範。有了插件框架更大的難度同樣也是如何將系統更好的模塊化/組件化。
好像微軟開源社區已經有插件框架的開發計劃。
@辰
我不想用LoadFrom，也不想用AppDomain.Create。我想用LoadFile。：）
AppDomain提供了物理隔離，但性能不行。因此，我不用隔離，但想支持多版本。MAF提供了物理隔離，SharpDevelop沒有提供。
@dicky
@道法自然
我看了核心代碼，是
Assembly assembly = Assembly.LoadFrom(fileName);
那麼基本上來說，這個插件是cs模式下的，而且是應用程序，不是服務程序。
因爲assembly.load是不可能卸載的。除非關係統。我的插件框架用了appDomain，因此可以直接熱插拔，直接卸載。
lz仍需努力。
引用辰：
我看了核心代碼，是Assembly assembly = Assembly.LoadFrom(fileName);那麼基本上來說，這個插件是cs模式下的，而且是應用程序，不是服務程序。因爲assembly.load是不可能卸載的。除非關係統。我的插件框架用了appDomain，因此可以直接熱插拔，直接卸載。
lz仍需努力。
剛吃過午飯回來,看到這麼多人關注很是興奮. :)
那麼我來解答你的問題.
先說 Assembly.LoadFrom(fileName):
如果我沒記錯的話這句代碼出現在 FilePackageProvider 中,在此框架中 FilePackageProvider 實現了 IPackageProvider 接口. 在此框架設計中 IPackageProvider 應是由框架使用者現實的, FilePackageProvider 只是本框架內提供的默認實現,當然你可以定義你自己的 IPackageProvider 實現, 然後在 PackageHost 構造時將其"注入"(詳見代碼 Addin.HostDemo.Program 處).簡單點說,你覺得 Assembly.LoadFrom(fileName) 不合適的話可以實現自己的 IPackageProvider.
再來說插件卸載:
由於時間比較緊所以此貼沒對設計細節做過多介紹,但如果詳細查看源代碼就不難發現 IPackageManager 接口與此接口的實現 PackageManager, 其中包含兩個相關方法 void RegistryPackage(string packageZipFileName); void DeletePackage(Guid packageId);意在註冊插件與卸載插件. 因爲此版是preview,所以你會發現 PackageManager 並未對這兩個方法提供功能實現,而是定義爲virtual,意在預留子類實現.那麼也就是說在設計之初對插件卸載是有所考慮的,並且此處未實現還有一個原因--我一直在權衡是否將這兩個方法放到 IPackageProvider 中.
從你所提到的這2個問題來看,我們倆所討論(關注)的並非同是一層面的東西.你所提到的建議我會認真考慮,希望繼續交流..感謝..
@fancycloud
不好意思,看來是我沒有表達清楚.
如果查看代碼你就會發現, 主程序啓動並沒有"加載"(實例化)插件,而只是獲取了插件描述信息(見代碼中PackageDescription).
具體的插件實例化過程應是由後續開發者決定的. 如 Addin.HostDemo 中是通過點擊菜單項後實例化並啓動插件的.
P.S. 此問題不屬於框架解決的範疇,何時實例化插件應由具體業務實現時決定.
權限的控制: 可在 IPackageManager 的 PackageAdding 事件中作相應權限控制, 並可在適當條件下取消 IPackage 的註冊操作.
@道法自然
看到您所提到的問題就知道您纔是行家.望多交流..
（1）用戶如何開發、調試、部署插件？
見代碼 Addin.HostDemo,Addin.PackageDemo,Addin.Services部分
（2）插件平臺和插件的結構；
忘記標明此代碼是基於.net framework2.0構建的
（3）插件間的依賴與通訊；
我對插件的理解見文中[概念]處[插件]段 -- "插件是可獨立完成某個或一系列功能的模塊.通常插件由宿主程序加載，不能獨立運行。",如果我理解的沒錯的話,我也提出一個問題:即然是獨立的功能模塊那何談與其它插件的依賴? 如果您的意思是插件間"數據依賴"的話那我們再繼續探討.
（4）插件的多版本問題和類加載機制；
見23樓.
（5）插件的擴展；
這問題似乎和上一個很像..（4）
（6）按需加載。
見24樓.
個人知識面有限,設計中不合理或理解有誤之處還望繼續指證與探討. 感謝..
仔細拜讀了下作者的文章，說實話感覺理論知識還是很不錯的，但是我並不贊同你的結構設計。首先，插件沒必要非設計成這樣複雜的結構，還需要HOST，感覺雖然文筆不錯，理論知識很好，但是可行性較差。 我最認同的還是人家QQ2009的插件模型，有機會還望您去研究下，可能我有點說過了，但是您那樣的插件方式 實在是讓我接受不了。 以上之言 僅代表我個人的看法，如有得罪，請見諒。
@dicky
整個插件核心應該就是這個IPackageProvider啊。lz仔細想想看看。
其他的可以說基本上是廢碼，不是說沒用的代碼，而是不是插件這個框架特有的。
什麼packagemanager之類的，我用最sb的List+interface都可以實現。
不過lz也別覺得我說的不是問題。您要把FilePackageProvider改成支持appdomain的，幾乎要花掉您另外50%的工作量。
就是說您開發一個addin框架和開發一個支持appdomain的功能難度是相當的。
@劍走偏鋒[E.S.T]
呵, 說的不過.
HOST譯爲宿主,不要理解爲主機喲.
至於"複雜的結構"您可查看下我在 #8樓 和回覆. 感謝,希望多交流..
基本上來說，如果把“插件”這個概念拋棄。lz只是實現了一個輕量級的基於接口的設計模式，也不算是spring，因爲還沒有實現鬆耦合。
等引入了xml配置，運行時加載之後就是一個簡單的spring。
等引入了appdomain之後，才能算是插件框架。
引用辰：
整個插件核心應該就是這個IPackageProvider啊。lz仔細想想看看。
其他的可以說基本上是廢碼，不是說沒用的代碼，而是不是插件這個框架特有的。
什麼packagemanager之類的，我用最sb的List+interface都可以實現。
不過lz也別覺得我說的不是問題。您要把FilePackageProvider改成支持appdomain的，幾乎要花掉您另外50%的工作量。
就是說您開發一個addin框架和開發一個支持appdomain的功能難度是相當的。
整個插件核心是 PackageManager.(稍後我會對此寫一說明性文章)
在設計此框架時我認爲 IPackageProvider 是個變化點,框架不應該強制 PackageProvider 只是從文件加載插件,試想如果這個插件是其它程序提供的對象呢? 所以更好的辦法是讓後續開發者決定從哪裏加載和如何加載插件.
個人覺得對於稱之爲框架的項目來講功能很重要,職責的劃分也很重要,但擁有足夠的擴展空間似乎更是重中之重.如果沒有足夠的擴展那就不應該叫做框架了,貌似應該叫"工具"(這句是我亂說的,嘿)..
很希望能有機會拜讀一下您提到的支持appdomain功能的PackageProvider.. 期待..
"基本上來說，如果把“BMW X6”這個標誌拋棄。它只是一個外表好看的四輪驅動的汽車，也不算是富田小卡，因爲還沒有車後箱。"
呵.. 開個玩笑.. :)
可能我對這個框架沒有足夠的功能描述導致您的一些疑惑,稍後我會對它進行一些簡要介紹,期待與您進一步討論.. 再次感謝..
@dicky
固執是件好事 也是件壞事
咱們磨磨嘴皮子 也就是打發一下時間 增添一些生活情趣 不過lz將來能走多遠 就要看lz了。
期待lz的下文
引用dicky：
@道法自然
看到您所提到的問題就知道您纔是行家.望多交流..
（1）用戶如何開發、調試、部署插件？
見代碼 Addin.HostDemo,Addin.PackageDemo,Addin.Services部分
（2）插件平臺和插件的結構；
忘記標明此代碼是基於.net framework2.0構建的
（3）插件間的依賴與通訊；
我對插件的理解見文中[概念]處[插件]段 -- "插件是可獨立完成某個或一系列功能的模塊.通常插件由宿主程序加載，不能獨立運行。",如果我理解的沒錯的話,我也提出一個問題:即然是獨立的功能模塊那何談與其它插件的依賴? 如果您的意思是插件間"數據依賴"的話那我們再繼續探討.
（4）插件的多版本問題和類加載機制；
見23樓.
（5）插件的擴展；
這問題似乎和上一個很像..（4）
（6）按需加載。
見24樓.
個人知識面有限,設計中不合理或理解有誤之處還望繼續指證與探討. 感謝..
（1）用戶開發方式或許是A）插件平臺正在運行，你創建一個工程到指定目錄；B）用戶開發插件需要引入插件平臺工程。這涉及不少的小細節。
（2）結構是指，比如插件平臺有幾個文件夾，哪個文件夾是放置插件庫，每一個插件的結構又是如何。
（3）獨立運行不代表沒有功能上的依賴，這種依賴可以是，A）插件A在運行過程中使用插件B的功能；B）插件A在開發過程中可能需要從B加載一個可複用的類。
（4）如果兩個插件引用了同一程序集的不同版本，如何解決？
（5）插件的擴展，是指一個插件可以對另一個插件進行擴展。
當然，要設計好一個優秀的插件平臺是沒有那麼容易的，需要從很多方面進行綜合考慮。但不管怎樣，都必須先從用戶角度來考慮，提供什麼功能，用戶怎麼使用這些功能。
至於有朋友提到的，引入AppDomain確實實現了插件的隔離性和可卸載，但是性能、複雜度和適應性大打折扣。如果沒有隔離性的話，在大型應用的話，安全性和可靠性比較難以保證了。
.NET沒有像Java中靈活的ClassLoader，因此，我們需要做一些衡量。
引用道法自然：
（1）用戶開發方式或許是A）插件平臺正在運行，你創建一個工程到指定目錄；B）用戶開發插件需要引入插件平臺工程。這涉及不少的小細節。
（2）結構是指，比如插件平臺有幾個文件夾，哪個文件夾是放置插件庫，每一個插件的結構又是如何。
（3）獨立運行不代表沒有功能上的依賴，這種依賴可以是，A）插件A在運行過程中使用插件B的功能；B）插件A在開發過程中可能需要從B加載一個可複用的類。
（4）如果兩個插件引用了同一程序集的不同版本，如何解決？
（5）插件的擴展，是指一個插件可以對另一個插件進行擴展。
當然，要設計好一個優秀的插件平臺是沒有那麼容易的，需要從很多方面進行綜合考慮。但不管怎樣，都必須先從用戶角度來考慮，提供什麼功能，用戶怎麼使用這些功能。
至於有朋友提到的，引入AppDomain確實實現了插件的隔離性和可卸載，但是性能、複雜度和適應性大打折扣。如果沒有隔離性的話，在大型應用的話，安全性和可靠性比較難以保證了。
.NET沒有像Java中靈活的ClassLoader，因此，我們需要做一些衡量。
請查看我的另一篇文章瞭解一下什麼叫"開發框架".
http://www.cnblogs.com/mix-up/archive/2010/01/01/1637437.html
開發框架,有所關注,有所不關注,請注意我文章使用的標題,再次重複一下是"基於插件式的開發框架".
基於插件式的開發框架: (1)概念及意圖
2010-01-20 22:18:38| 分類： 插件|字號 訂閱
新的一年開始了, 首先祝大家心想事成, 萬事如意!
在上一篇文章(基於插件式的開發框架: 源碼)中發佈了近期寫的一個框架源碼, 值得興奮的是很多人都參與到了討論, 並提出了寶貴意見.
由於發佈源代碼之初未對其框架設計做過多說明, 所以可能導致大多數人對這個框架產生了一些疑惑. 那麼本人就此對框架做個介紹, 希望大家能從中更進一步瞭解本框架的設計初衷, 也希望能與大家交流想法.
在上一篇文章中我對插件式的概念做了個總結(如下), 意在大家能對插件式從概念上有個初步瞭解.
插件: 插件是可獨立完成某個或一系列功能的模塊. 通常插件由宿主程序加載, 不能獨立運行.
宿主: 宿主是承載插件運行的環境, 爲插件提供基本服務. 通常插件由宿主程序管理和控制.
插件式: 通常是由開發人員編寫宿主程序, 並預先定義好系統提供基本服務接口和插件接口.然後由其他開發人員根據系統插件接口編寫插件功能. 通常插件以一個獨立功能模塊的形式出現. 對於宿主程序來說並不知道插件的具體功能, 通常宿主啓動時檢索插件信息, 並根據預定的插件接口裝載插件.
但基於上一篇文章評論中大家提到的一些問題, 我覺得有必要再來介紹一下開發框架的概念.
開發框架(也可稱其爲框架): 開發框架是一個具有部分功能的應用程序半成品, 它提供了可在應用程序之間共享的可複用的公共結構. 後續開發者把框架融入到自己的應用程序中, 並加以擴展以滿足他們特定的業務需要. 通常框架是成熟的、不斷升級的軟件. 框架是一個可複用的設計構件, 它規定了應用的體系結構、闡明瞭整個設計、協作構件之間的依賴關係、責任分配和控制流程,最終表現爲一組抽象類以及其實例之間協作的方法.
如果您瞭解了以上這些概念, 我想從文章中的標題("基於插件式的開發框架")中就應該大體上了解了它要做的工作. 在瞭解這兩個關鍵概念(插件式,開發框架)基礎上, 我會在稍後的幾篇文章中陸續與大家分享我在這份源碼設計開發過程中的思路和想法.
此框架的設計意圖
我想如果沒有前面提到的"概念"部分, 可能會有一些人不明確這個名爲<基於插件式的開發框架>的東西要幹什麼. 這也是我把概念部分放到頂端的原因--希望它對理解這個框架的意圖能有所幫助. 那就本插件式開發框架來說結合以上概念, 其實我們是要編寫一個能闡明協作構件之間的依賴關係、責任分配和控制流程的、可複用的、具有部分功能的插件宿主, 並預先定義好擴展接口供後續開發者使用.
雖然前面寫了很長的"鋪墊", 但一時間似乎仍不太容易理解意圖本質, 不過沒關係在稍後幾篇中我會逐步細化每一個過程.
基於插件式的開發框架: (2)責任分配
2010-01-20 22:35:37| 分類： 插件|字號 訂閱
公司裏有兩部電話, 是用來做支持的, 一個是技術方面的, 一個是業務方面的. 客戶會
打電話過來諮詢一些問題. 但是, 出現一個小問題, 客戶通常分不清他要問的問題是業
務的還是技術的, 所以總是會打錯電話. 公司內部麻煩不說, 造成客戶滿意度直線下降.
後來領導要求將兩部電話換成一部, 這樣就避免了客戶打錯電話的問題. 但事情並沒有
到此結束, 由於技術部和業務部日常工作都比較繁忙, 電話換成一部後時常無人接聽,
原因很簡單, 技術部的人想, 電話可能不是諮詢技術問題的, 讓業務部的人接聽去吧,
業務部的人的想法異同. 領導瞭解到情況後, 立即部署"專職人員"專注電話接聽工作,
從此電話接聽問題得到了解決.
以上是一個簡單案例, 從中我們可以看出責任分配不明確所帶來的一些影響.
再回到插件式開發框架部分, 簡要說下本框架是如何進行責任分配的.
上一篇意圖中很明確的目標是構造宿主程序, 又從基本概念中瞭解到宿主是管理和控制
插件的, 那麼框架中宿主內部各構件的責任如何分配似乎已顯現出了大半.
插件管理(源碼中IPackageManager)
插件管理即對裝載插件,註冊插件,移除插件等操作的管理.
插件控制(源碼中IPackageController)
插件控制即對運行(啓動)插件,停止(卸載)插件進行控制.
前兩篇文章的評論中有人說你這個開發框架"什麼packagemanager之類的，我用最sb的
List+interface都可以實現。". 那麼我希望能通過上面的案例說明我在此框架中使用
packagemanager的原由 -- 每件事物都應有"專職人員"處理.
公司裏有兩部電話, 是用來做支持的, 一個是技術方面的, 一個是業務方面的. 客戶會打電話過來諮詢一些問題. 但是, 出現一個小問題, 客戶通常分不清他要問的問題是業務的還是技術的, 所以總是會打錯電話. 公司內部麻煩不說, 造成客戶滿意度直線下降. 後來領導要求將兩部電話換成一部, 這樣就避免了客戶打錯電話的問題. 但事情並沒有到此結束, 由於技術部和業務部日常工作都比較繁忙, 電話換成一部後時常無人接聽, 原因很簡單, 技術部的人想, 電話可能不是諮詢技術問題的, 讓業務部的人接聽去吧, 業務部的人的想法異同. 領導瞭解到情況後, 立即部署"專職人員"專注電話接聽工作, 從此電話接聽問題得到了解決.
以上是一個簡單案例, 從中我們可以看出責任分配不明確所帶來的一些影響.
再回到插件式開發框架部分, 簡要說下本框架是如何進行責任分配的.
上一篇意圖中很明確的目標是構造宿主程序, 又從基本概念中瞭解到宿主是管理和控制插件的, 那麼框架中宿主內部各構件的責任如何分配似乎已顯現出了大半.
插件管理(源碼中IPackageManager)
插件管理即對裝載插件,註冊插件,移除插件等操作的管理.
插件控制(源碼中IPackageController)
插件控制即對運行(啓動)插件,停止(卸載)插件進行控制.
前兩篇文章的評論中有人說你這個開發框架"什麼packagemanager之類的，我用最sb的List+interface都可以實現。". 那麼我希望能通過上面的案例說明我在此框架中使用packagemanager的原由 -- 每件事物都應有"專職人員"處理.
發表評論
就這麼幾個字？就IPackageManager和IPackageController這兩玩意，每個各一行解釋？然後起了個響亮的名字“責任分配”？
要做的話，做好一點，專業一點。當然包括你寫的內容，要公開的話，就大大方方漂漂亮亮的公開，如果不公開，乾脆什麼都不寫，以免被認爲是遮遮掩掩。都不知道是你實際水平不高，還是寫作水平不高，還是故意遮遮掩掩。
當然，這是我個人的評論，你可以不接受。
引用道法自然：
就這麼幾個字？就IPackageManager和IPackageController這兩玩意，每個各一行解釋？然後起了個響亮的名字“責任分配”？
要做的話，做好一點，專業一點。當然包括你寫的內容，要公開的話，就大大方方漂漂亮亮的公開，如果不公開，乾脆什麼都不寫，以免被認爲是遮遮掩掩。都不知道是你實際水平不高，還是寫作水平不高，還是故意遮遮掩掩。
當然，這是我個人的評論，你可以不接受。
1.內容的多少似乎和表達的思想沒有直接關係吧?
2.我講的不是"責任分配"的內容嗎?這也太霸道了吧,用個名詞都是罪?
3.什麼是好?什麼是專業?請發佈你所謂專業的代碼或文章讓大家看看.
4.源代碼都放出來了請你告訴我,"掩"哪裏?
5.你覺得沒看懂可以討論,但請明確一點,ME不是來這比水平高低的.所以你的"都不知道是你實際水平不高，還是寫作水平不高"我沒法給你一個答案.恩,ME的寫作水平一般,這點ME接受.(說這話並沒有表示技術水平高的意思..得說明一下,免得再挨訓.. -_-!)
@道法自然
現在博客園就是你這種人越來越多了,說話刻薄，最終弄的整個博客園就那麼幾個人跳來跳去，還分幫結派。
看上去是維護了整個首頁的質量，實際上冷了我們這批新手的心。
另外博主的這個框架寫的其實挺不錯的，他的源碼都放出來了，代碼的質量至少在博客園也算比較好的了，你有看過麼？
對於說話刻薄者，可以無視不予理會。
該吃吃，該喝喝，遇事別往心裏擱，泡泡澡，看看錶，舒服一秒是一秒！
你的源碼我稍微瀏覽一下，看了一下結構和幾個名詞，於是我就沒有多看了。我是被“責任分配”這四個字吸引的，因爲我從來沒有看到其它插件平臺提到過這四個字。不過，進來看了就大失所望。
就這麼幾個字？就IPackageManager和IPackageController這兩玩意，每個各一行解釋？然後起了個響亮的名字“責任分配”？
>> 你可以指出我所說的這些話錯在哪，本文不就是提一下兩個類的用途。至少你稍微認真的談一下要讓人知道什麼，原理嗎？不是。
要做的話，做好一點，專業一點。當然包括你寫的內容，要公開的話，就大大方方漂漂亮亮的公開，如果不公開，乾脆什麼都不寫，以免被認爲是遮遮掩掩。都不知道是你實際水平不高，還是寫作水平不高，還是故意遮遮掩掩。
>> 遮遮掩掩不是指代碼公開了就不是了。既然你說的思想重要，那就談一下你的思想。不過，你都以代碼就是思想爲由不提，因此你要麼是寫作不行，要麼是理解不到位，要麼就是不想寫。你可以否定，但是我這樣指出來對你沒有壞處。當然，這也或許是因爲不認真造成的假象。
我沒有公佈什麼源代碼，除了一個應用的代碼之外，不過，我很認真的公佈了我開發組件的思想。源碼沒有公開是因爲我目前做的還不到位，註釋、缺陷、易用性等方面還不夠完善。
打擊你不會給我帶來什麼好處的。不過，估計你經驗不多，不管是代碼經驗還是對自己的認識（即自知之明），所以我直接說出了我看到內容的想法。
我也說了，你可以接受，也可以不接受。
補充一點：如果要做自己的東西，應該要學會換位思考。換位思考可以簡化爲，寫的文章別人怎麼理解，有什麼收穫。從而，也可以知道，做的東西別人怎麼用，他們嫌不嫌麻煩？如何改進。
我也只是一個菜鳥，不專業。不過，至少覺得這文章寫的不太認真，有點湊數的意思。下文是一個專業人士寫的一篇文章。
http://sardes.inrialpes.fr/~krakowia/MW-Book/
@道法自然
首先,請認真閱讀本博客中以"基於插件式開發框架"字樣開頭的文章,或者先自己弄明白什麼叫"上一篇".先弄明白基本的東西再來評論,不要認爲所有名稱中帶有"插件式"字樣的都得和你認爲的"插件式"扯上關係.
-------
我是被“責任分配”這四個字吸引的，因爲我從來沒有看到其它插件平臺提到過這四個字。不過，進來看了就大失所望。
你去過北極麼?.. 不懂什麼是“責任分配”請看上一篇文章.
-------
就這麼幾個字？就IPackageManager和IPackageController這兩玩意，每個各一行解釋？然後起了個響亮的名字“責任分配”？
>> 你可以指出我所說的這些話錯在哪，本文不就是提一下兩個類的用途。至少你稍微認真的談一下要讓人知道什麼，原理嗎？不是。
首先,請看上一篇文章.
其次,本文是結合源代碼對其進行介紹(上一篇中已有說明).
再次,別告訴我你沒看懂文章中例舉的案例,也不要再SS的說是爲了看“責任分配”四個字進來的,否則這個評論我只當YRYY.
-------
要做的話，做好一點，專業一點。當然包括你寫的內容，要公開的話，就大大方方漂漂亮亮的公開，如果不公開，乾脆什麼都不寫，以免被認爲是遮遮掩掩。都不知道是你實際水平不高，還是寫作水平不高，還是故意遮遮掩掩。
>> 遮遮掩掩不是指代碼公開了就不是了。既然你說的思想重要，那就談一下你的思想。不過，你都以代碼就是思想爲由不提，因此你要麼是寫作不行，要麼是理解不到位，要麼就是不想寫。你可以否定，但是我這樣指出來對你沒有壞處。當然，這也或許是因爲不認真造成的假象。
除了你所說的"IPackageManager和IPackageController這兩玩意"外,文章開頭與結尾部分不是"小夜曲"..
-------
我沒有公佈什麼源代碼，除了一個應用的代碼之外，不過，我很認真的公佈了我開發組件的思想。源碼沒有公開是因爲我目前做的還不到位，註釋、缺陷、易用性等方面還不夠完善。
是那篇<總結：我喜歡的軟件體系結構——分層、模塊化與OSGi>麼?
的確文章內容比我的長,但仔細看下更像是對各"技術"的介紹.
"我以前喜歡追求有藝術的代碼，什麼是有藝術的代碼呢？那就是要有技術含量，殊不知，簡單就是藝術！"--是你總結的麼,似乎很有深度.
沒有註釋,存在缺陷,易用性差都沒關係,能發給ME一份麼我學習一下.
我的郵箱: [email protected]
-------
估計你經驗不多，不管是代碼經驗還是對自己的認識（即自知之明）
請查看瀏覽器地址欄上的地址是不是www.cnblogs.com, 這裏是博客園技術社區. (P.S. 評論別人的人品是不道德的)
-------
英文文章看不懂,能幫忙給翻譯成中文麼?.. 謝謝.
毫不畏懼，再變態也不夠變態羣的人變態
菜丁 加油！！
覺得有水平、看了有收穫就“贊一下，捧個場”，覺得不咋樣就飄過算了，也或簡單的給些建議也算是指點指點人家，幹啥把板磚拍得這麼兇呀，搞得一點也不和諧，不利於安定團結！
我沒有必要說太多了。我花了大約45分鐘看了你的代碼（原來只是看了一下名詞，一般來講，小的細節就可以看出一個人或代碼的質量）。大體邏輯應該如下：
（1）這個框架的結構是IHost =1:N with IPackageServiceProvider=> IPackage，利用預先定義的服務接口實現Host和Package的交互。這種方式類似於WF中的Service。
（2）Host通過使用IPackageManager對所有的Package進行管理，PackageManager使用PackageProvider遍歷獲取所有的PackageDescription，然後爲每一個Package創建一個PackageController並保存起來。
（3）每一個特定的應用都必須實現其特定的Host和ServiceProvider，以及若干Package。Host將以獨特的方式來使用每一個插件，它們的交互利用特定的服務實現交互。就比如WinForm的插件應用，大概是主窗體實現IHost，然後利用輔助類創建插件，在某個動作觸發時，去加載或者卸載插件。在例子，你用了一個Tag來存儲對應的插件名稱（我2005年實現的通用窗體框架也採用這種狡猾的方式），然後利用這個Tag加載/卸載插件。
（4）對於你的例子，我沒有太多的時間和精力仔細看。不過大體猜測的出來。
因此，我感覺你用一篇的篇幅就可以把這個框架的內容描述清楚了，不至於用那麼多的篇幅，特別是像這一篇沒有兩句話的文章。
優缺點我覺得我已經沒有必要再說太多，你覺得你的框架好就行。忠言逆耳，實在的話總是不太好聽的。我原來說的不好聽的話呢，你不用接受。我收回我說過的話。
此外，再辯解一句“估計你經驗不多，不管是代碼經驗還是對自己的認識（即自知之明）”，此話不是想攻擊人品，不過，我承認，我在說這句話的時候，自大了，覺得我應該比你經歷的事情多，這是我的錯。我只是想說的是，每個人最好都有對自己的優缺點有所認識，從而能夠更好的吸取別人的優點，因此，必須有自知之明。我也有自知之明，那就是我屬於菜鳥，比較笨，屬於反應遲鈍型，一般都會比別人反應晚一步。
至於可以拿得出手的代碼，我暫時不方便給你，因爲這些代碼給我帶來了若干倍於上班的收入，我自己的公司不允許我現在這麼做，我們有我們的開源計劃，需要依賴這個計劃給我們帶來更多的保障。不過，我可以說一下我們組件開發方法：（1）用戶場景設計，即考慮好用戶如何使用這個組件，其好處是我們可以根據場景不斷優化用戶的應用，從而達到簡單是美的原則，這個原則是對用戶而言的；（2）必須有全部接口的類圖，VS裏面的類圖非常的方便，Eclipse裏面就稍微麻煩一點；（3）有重要的設計規範；（4）有API說明書，這個可以通過文檔工具自動生成，因此需要對公開接口進行完善的註釋；（5）基於SVN代碼管理；（6）單元測試和集成測試。其實本來還應該具有完善的用戶指南、缺陷管理和持續集成，但是我們只是在下班時間做這些東西，沒有足夠的時間。
道法自然兄弟就別認真了。上次我也說過了。不過lz似乎非常的堅持。
說白了lz的東西就是個設計模式，不過感覺也不知道是什麼模式。
不過lz當技術人員比較適合。缺少跳躍思維，1+1=2，一步一步邏輯性強。不適合做manager類。
如果lz長期堅持下去，會是一個很專的engineer。但是稍微跨跨行業就完蛋了。而且也有可能專長的方向被淘汰之後，出現危機。
List<T> = IPackageManager
interface = IPackageController
這樣做個稍稍跳躍性類比不知道是否能夠說明白問題。
List<T> 是個class，只不過是微軟寫的一個class。如果微軟把List<T>命名爲PacakgeManager<T>。那麼lz會不會更加的清晰？
幾句爭論最終淪爲“忠言逆耳，實在的話總是不太好聽的。我原來說的不好聽的話呢，你不用接受。” 俗……
@辰
@道法自然
很高興 @道法自然 能抽出45分鐘去看我的代碼,你所指出的1,2,3點也基本描述了這個開發框架的工作流程, 但描述流程並不是寫這幾篇文章的本意, 流程只能讓人知道如何使用. 而我是希望能讓其它人瞭解到設計中的一些思想和經驗. 當然, 我要承認自己的寫作水平較差, 一些想法可能表達的不夠清楚, 但意圖是明確的.
我一直認爲在討論中學習是個不錯方式, 我也很高興能和大家探討, 但這需要建立在交流學習的心態之上. 但你2樓的回覆實在讓人難以接受, "小菜鳥經不起大板磚", 望你能理解.
在技術社區裏說太多與技術無關的沒意義,那回到技術,我簡要說下 你和@辰 我們對這個開發框架的分歧之處.
你的上面的回覆基於說出了這個開發框架的工作流程與關鍵要素,說白它就是裝載插件,然後讓後續開發者能夠方便的管理與控制插件.
對於此開發框架來說,它沒法預知到後續使用者所使用的宿主類型(窗體程序/控制檯程序/其它),所以使用了抽像類型PackageHost, PackageHost中封裝檢索插件操作,並提供插件管理訪問點,後續開發者由此抽象繼承,從而獲得插件管理功能,並且不阻礙他對宿主類型的選擇,讓後續開發者有足夠的擴展權.
像宿主類型一樣,在設計此框架時我認爲插件的來源也是無法預知的,框架不應該強制只是從文件加載插件,試想如果這個插件是其它程序(服務)提供的對象呢? 所以它也應該由後續開發者決定從哪加載和如何加載,仔細查看代碼你會發現PackageHost構造時是可以"注入"自己的IPackageProvider的,而FilePackageProvider只是框架中的默認實現方式,對於簡單應用它已經足夠了,當然如果有複雜應用的比如你前些時候回覆中提到的"兩個插件引用了同一程序集的不同版本"等你可以實現IPackageProvider定製基於自己需求的插件提供者.但對於本框架來說這部分是不被關注的,它應該由後續開發者決定. 這也是你和@辰我們的分歧之處.
@辰 所說的問題本文正文處已給出瞭解釋,本開發框架的客戶(後續開發者)必須有明確的訪問點(兩部電話與一部電話的問題),同時框架本身也應明確誰來做什麼事(有"專職人員"專注電話接聽工作).我不否定@辰提到的List+interface,但是我覺得使用PackageManager能更好的顯現其職責,並有利於後續開發者的使用.
寫的有點長, 但由於本人表達能力原因, 我依然沒法確定此段文字是否能被大家所理解, 技術方面的不明之處請繼續探討. 感謝各位.
@Ling2008
@FrankYu
感謝二位的支持與理解.
@別愛上哥，哥只是個傳說！
恩,下次我努力寫的豐富些. 感謝..
@dicky
我應該寬容點，這是我的錯。關於你FW的設計，默認實現及其預留的一些擴展，我能理解，Core的代碼我已經都看完了。我對你的代碼和你說的都能理解，只是你不知道我的意思。每個人長的都差不多，想的也差不多，這是人性。FW一般思路都是“抽象——默認實現——擴展”，只不過存在好與壞的區別而已。我雖然說了不討人喜歡的實話，不過，你不用在意，自己認爲自己的FW好就行了。不拘小節，注意細節。其它話，包括對這個FW的評價，我就不再說了。