在2005年的時候，我曾經基于.NET 2003開發了一個小的組件，這個組件的目的是為了解決模塊化開發和模塊復用的問題。我將該組件命名為Common Form Framework，它的目的是允許每一個開發人員獨立的開發自己的模塊且可以直接專注于業務模塊，然后通過配置可以快速將所有開發人員開發的業務邏輯窗體集成到這個組件中。

　　該組件的思路如下圖所示。該組件提供了一個如“2”標識的空的窗體，每一個開發人員通過編寫一個如“1”的XML配置文件即可將一個模塊的功能附加到空窗體，最終組合成一個如“3”所示的軟件產品。

　　這個組件成功的應用在一個由9個人合作開發，歷時1年的應用系統開發中。它的想法和Microsoft Composite Application Block有一些類似，不過沒有CAB那么強大了。

　　在參考了CAB和經歷更多應用系統之后，我發現該組件有不少缺點，比如：模塊化定義不夠標準、界面元素無法擴展、模塊交互非常復雜、功能復用低、不能應用于Web或者其它應用環境等。為此，我參考了CAB和SCSF的一些功能，并在2007設計了一個Commom UI Platform規范，旨在設計一個更為強大簡單的模塊化快速開發平臺。

　　不過在2008年的時候，我有了更多的想法，提出了一個UIShell產品構思。UIShell是英文User Interface Shell的縮寫，中文譯為“用戶界面外殼”。它是由一個軟件模板框架。它由框架層、服務層、Shell層和系統模塊層組成，提供了基于UIShell的軟件設計和開發規范。 Shell中文譯為“外殼”，它是應用系統的主界面，由可擴展的界面元素（如菜單、工具欄）和可替換的界面（如顯示區）元素組成，如下圖所示。

　　這個產品面向的用戶有2種：（1）開發人員——該產品能夠為開發人員提供一個模塊化設計規范、通用的界面框架和通用的服務，從而使得開發人員可以直接設計業務模塊，不需要關心軟件的界面、用戶體驗等；（2）最終用戶——最終用戶不需要去購買任何軟件，可以通過基于該平臺的軟件超市中下載到所需的界面框架和應用模塊，然后自己組裝成最終的軟件。

　　在我現在看來，當時的想法確實有點瘋狂，因為我想的太簡單太遠大了（不過，有時候還真需要瘋狂才能干點什么，：）），不過我那會一點都沒有意識到這點。我當時組了一個UIShellDev Team。我很驕傲的告訴團隊，“一旦我們實現了UIShell，我們或許能夠為軟件行業開辟一個新的方向，為其貢獻點什么”。

　　于是我們便開始了UIShell產品之路，我們瘋狂的學習了Enterprise Library、SCSF、SharpDevelop、Egeye Addin、MAF、MEF等，分析了SCSF的源代碼、SD源代碼，學習了Framework Design Guideline，關注每一個新出現的產品并分析競爭優勢與劣勢（如Google App Engine、Sina App Engine、MEF等，我們不能開發一個對開發人員來講沒有用且過時的產品，因此需要時刻保持警惕），制定了產品開發規范——“用戶場景設計規范、需求規范、設計規范、質量保證體系等”…… 這個產品設計目標以“易用性”為首要目標，這意味著我們做任何功能都應該先想到用戶，并模擬用戶的行為習慣來不斷的優化產品的設計。然而這條路并沒有像我預想的那么容易，我原來以為這個產品早該在2009年底就發布了。設計的過程中，問題一個接一個，且由于我們團隊是兼職的，進度比我預想的慢了許多。更為重要的是，當時想法是基于SCSF來做的，SCSF太過于復雜，并不能夠滿足我們的需求。在一個偶然的機會，我接觸了OSGi規范，并利用業余時間將OSGi規范翻譯了。看了OSGi后，我眼前一亮，我意識到了這就是我想要的。然而OSGi是基于Java的規范，由于.NET平臺和Java平臺的差異，我們需要設計一個符合.NET平臺的規范。于是，我們便動手自己設計了OSGi.NET規范，在設計這個規范時，我們借用了OSGi規范但調整了它的目標，即OSGi.NET的定位是一個滿足.NET不同應用環境的通用模塊化運行時，它實現了OSGi的模塊化與插件化、面向服務、模塊擴展和安全性的功能。

　　OSGi.NET規范及接口設計在2008年底設計完成，我記得當時完成設計的時候，我正在美國的Dublin，通過Email把設計的圖紙和規范發送給UIShellDev Team。這是該規范的初稿。在接下來的日子里，我們不斷的對設計進行重構，最終在2009年8月份實現了內核原型，在2009年10月份完成了OSGi.NET設計最終稿。當然，在重構的過程中，團隊其他成員已經開始動手設計了。在這里我們設計了一個能夠通用于各種.NET運行環境的模塊化運行時，它實現了UIShell產品所有功能，并且易用性依然保持。我們自行設計了模塊化規范、模塊運行時類加載規范、SOA規范和擴展規范、開發與調試規范。不過，中間有一個決策比較困難，因為ASP.NET不同于WinForm、WPF和Console，它必須宿主在Web Server。那么，我們的爭論就在于——是IIS宿主模塊運行時還是模塊運行時宿主IIS呢？如果模塊運行時宿主IIS，那么它就有完全的控制權，不夠運行于IIS的模塊與模塊運行時的其它模塊間的通訊就麻煩了，因為這是跨進程通訊。如果IIS宿主模塊運行時，那么模塊運行時就比較被動了。最終討論的結果是采用第二種方案，因為這種方案性能高、簡單。在完成最終稿設計時，產品設計的所有問題便解決了。我們便投入所有的精力去實現。

　　目前UIShell產品設計與實現已經進入尾聲，這也意味著軟件超市的基礎平臺已經基本構建完成。我們實現的OSGi.NET內核已經能夠成功的宿主在.NET各種不同環境，并且各種環境的設計思路、開發思路完全一致。軟件超市以后將會有不同環境的Shell模塊、通用服務和應用模塊，這樣，用戶和開發人員都可以去下載和組裝軟件，并且也可以去貢獻自己開發的東西。

　　還需要提到的是，UIShell產品在實現的過程中，關于質量保證體系的構建。事實上，產品設計的初始階段，我是很希望所有的東西都能夠非常的完善，包括質量保證體系，我當時是一個完美主義者。不過，我們并沒有足夠的資源來支撐“完美”。在這一過程中，我學會了妥協、學會了“軟件中庸”，我們只能把有限的資源投入到最需要的地方，況且每一個階段的目標還不同。當然了，我們現在已經構建了一個簡單且有效的質量保證體系，它基于“Subversion/TotoiseSVN/AnkhSVN + CruiseControl.NET/NAnt + BugTracker.NET”實現。Subversion提供了類似ClearCase的配置管理功能，是一個開源免費的產品，它提供了強大的Branch/Tag管理，Branch/Tag是我當時選擇配置管理工具的首要要求，這是產品線管理的必備功能。CruiseControl.NET/Nant用于持續集成，在每一個代碼更新時，它都會自動Build，我們可以看到產品線是否健康，此外，還有一個很重要功能，我們可以隨時構建一個新的用于測試的安裝包。BugTracker.NET也是一個開源的缺陷管理工具，我們可以隨時創建Bug。它在每次Bug更新時，都會向團隊發送郵件。它提供了強大的缺陷統計管理，在Bug Fixing階段，我們可以方便的安排產品不同階段需要Fix的所有Bug，也可以用于統計每一個人的工作量。當然了，我們還根據需要對BugTracker.NET進行了改進，主要有2個：（1）當代碼提交時，Bug狀態自動變為Check in并發送郵件；（2）加入代碼審計功能，可以方便的為每一個Bug生成代碼審計包，從而使得我們可以方便查看每一個Bug所做的更改。以下是一個BugTracker.NET Email通知示例。

　　目前UIShell內核產品由安裝包工程、VS插件工程、Remote Console工程、OSGi.NET工程、SaaS工程、Web Extension工程、Shell工程、測試工程和Help工程構成。只要在不同環境中采用如下方式宿主模塊運行時，這個環境便具有了OSGi.NET的所有特性。現在經過測試的環境有控制臺、WinForm和ASP.NET，接下來我們在完善了文檔、Sample之后將發布第一個版本，并在下個版本中實現對更多環境的集成測試，完善產品，并構建軟件超市網站。

　　此外，我們還將構建一個SaaS商店，不過這是另一個產品了，我將會在以后介紹我們SaaS商店產品了。最后我要感謝UIShellDev Team的所有成員，他們為產品的構建付出了很大的努力，提出了很多有建設意義的想法，這個產品是一個團隊的結晶。在產品研發過程中，我們體驗了團隊1+1>2的力量。沒有他們的付出，UIShell產品是不可能實現的，更別提其它宏偉的想法了。每次想起與團隊開發過程中的細節，我都非常的驕傲和感動，這些人真nice！

namespace SimpleBundleShell
{
    class Program
    {
        static void Main(string[] args)
        {
            // 啟動模塊化運行時，這樣，它就會自動的從plugins加載所有模塊
            // 并啟動它們。在這里，一個模塊=普通.NET項目 + Manifest.xml。
            // 因此，模塊的開發和我們原來開發一個.NET項目的方式是完全一樣
            // 的，我們不需要學習新的知識。
            using (BundleRuntime bundleRuntime = new BundleRuntime())
            {
                bundleRuntime.Start();
                Console.WriteLine("Press enter to exit...");
                Console.ReadLine();
            }
        }
    }
}        

        

        
        
      
        
NET技術：瘋狂的想法——基于.NET的軟件超市平臺構想與5年實現之路，轉載需保留來源！
        
鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯系我們修改或刪除，多謝。