筆記本: 一個程式呼叫的架構概念

這是我之前花了幾個月的時間做的一個小專案，其中的一個機制，算是專案中我花最多時間去思考的部分。

這個專案要做的是一個選單系統，大概就像是Windows的開始功能表打開的那個感覺，裡面會有多層目錄，也會有很多可執行的程式項目，只是這個選單要用來掛載各個自行開發的系統，所以要能方便維護選單內容，並能支援系統的各種權限及執行設定。

如果要在Windows系統下建置系統的話，是可以利用AD來控管權限，在regedit及文字檔中存放執行的參數設定，但是這種做法對各個零散的小系統而言比較不易調整維護，而且AD並不是家家都有。

這個選單系統其實已經存在，從早期各個系統都建立一套自己的選單，到後來有人開發了一套整合性的選單，各系統只要把程式功能掛上去就能使用，而這個選單的功能也很簡單，就只是用System Call呼叫要執行的程式而已。

在這個系統背後其實也有一個資料庫，用來存放程式的詳細資料，像是要去哪裡找到程式、要傳遞哪些執行參數之類的，在架構上的特色是，程式資料只供選單存取，其他的系統是不能接觸這個資料庫的。

只是這裡產生的一個問題是，如果是兩支程式功能之間想要互相呼叫並傳遞工作階段參數時，應該怎麼實現？尤其在架構上資料庫隔離的限制，程式A是沒辦法得到要程式B的執行時必要資訊，當然也沒辦法呼叫它。

在解決這個問題時，我使用了一個叫做程式呼叫器的中繼物件，專門負責程式的呼叫執行及傳遞參數，選單及程式只要建立這個呼叫器的參考，就可以利用它來呼叫其他程式，當然也可以把工作階段的參數，透過呼叫器傳遞給另一支程式。

另外程式的呼叫方式，也改由物件呼叫的方式（每支程式做成一個類別，並包裝成DLL檔，讓呼叫器用動態呼叫的方式執行），也因此才能夠讓選單及各支程式共同使用同一個呼叫器參考。

這種做法對Windows來說，從選單到各個被呼叫的程式功能，都被視為同一個應用程式，所配置的記憶體空間也是共用的，在傳遞參數時用Function Call來處理就可以了，其實應該算是滿理想的做法。

只是我一直對於每一支程式都要建立一個呼叫器的參考（知道自己的呼叫是從哪裡傳來的，要呼叫別的程式的時候才知道要去哪裡找呼叫器）的做法不是很滿意，但是在找不到解法的情形下，這個專案還是這樣完成了。

不過後來我接觸到了一個叫做WCF的東西，覺得這應該是我在找的解決方法，因為我曾經一度想要做一個負責呼叫程式及控制與傳遞工作階段參數的常駐程式，以供這個架構使用（也就是把程式呼叫器做成常駐程式），只是因為沒有能力完成這樣的架構而未實行，但是WCF不但能達成我期待的功能，而且似乎比常駐程式更適合（也可以說是服務型態比常駐程式型態更適合）。

首先使用者端的選單只會是純粹的介面，選單的內容以及選單的動作都交給WCF來負責，可以真正做到程式面及資料面的隔離，另外除了Windows Form的程式之外，如果要製作網頁版的選單，也只是打造一個網頁的介面，所有的資料及邏輯處理都不用再重新撰寫，而且也可以用來呼叫網頁或網頁程式。