公司專屬應用程式平台設計雜想

 

   軟體體系本身已經很複雜，更何況用以構建軟體的架構。同電腦硬體的發展一樣，我們只有在不斷的學習、不斷的思考中進步。從前人的經典中學習積累知識，從成功的實踐中學習經驗，從失敗的過程中總結教訓。本文的內容也正是我學習、實踐、和思想的過程。希望能有效與您溝通。

 

   首先，在諸如"架構"、"架構"這些詞上請不要和我太計較。只要你能清楚我所要表達的意思就好，不要在為這些詞語的解釋上分散我們的主題。

   為了使我們的討論清晰，而且能在我們掌控之中，我架設了一個以下的虛擬環境（此環境是現實的，為討論方便做了一定程度的簡化）。我們要針對以下的環境設計一套平台方案而不是做一個通用的商業軟體平台。

一個虛擬環境：

我們（M企業）為一個行業提供資訊化系統整體解決方案。我們的客戶（A 集團）的典型的組織架構是這樣的:      首先我們不打算構建一個大型的ERP產品來滿足各層級使用者的需求。這樣做有曆史的原因、可行性、以及資訊收整合本，系統整合成本、需求規範層級，而且這樣做事有利可圖的。我們可以做好多重專案，分別賣給A、B2、C3-1、C1-2。而且可以不斷的為他們升級而在擷取項目收益。      但這樣以項目為核心的做法是企業陷入了一個很大的僵局。人員、資源、以及管理都出現了極大的浪費。    現在獲得企業高層的支援。準備在我們的軟體公司內部成立一個平台研發中心，目的在於構建一個基礎的開發平台還搭建現有的5種類型的項目。   人力資源管理系統 --集團級、公司級、分公司級 物資管理系統     --公司級、分公司級 銷售運輸系統     --集團級、公司層級 財務系統（暫時由其他系統代替，考慮整合） --集團級、公司級、分公司級 管理戰略分析系統 --集團級

 

出於種種因素的考慮，我訂製了一個基本的不完善的平台目標，隨後隨著我們認識的不斷提高會陸續增加新的內容。

平台的目標:

1. 極大的減少項目開發週期以及實施周期。
2. 穩固的底層架構、以及可擴充性。
3. 可配置的N層分布式物理架構。
4. 允許開發人員無障礙的使用。
5. 提高系統整體效能。
6. 助於VSX的IDE工具。
7. 提供非開發人員層級的現場輔助實施工具。
8. 儘可能的應對因需求變更，而需要對架構層級做出修改。

    當然現在我們的分析階段還僅僅是構想可行性階段，還沒有引入真正的業務需求，而且我認為也還沒有到那一步。可以先針對每一項目標還搜集一些好的想法。也不必太拘泥做出一些非常眩的模型圖，當然為了思路方便我們可以使用白板和腦圖。

 

    對於減少項目周期我想到了這些：

     我盡量從開發的角度考慮能夠提高開發效率的方法，而不是從過程管理控制的角度出發。當然也有些很容易想到的東西被我遺忘了也是必然的。如：ORM工具。也許他提供了代碼產生工具或資料庫產生工具。但此刻我就想到這麼多，即使想到的那也只是一些思路。我們可以從業務開發人員的角度在考慮這個話題。業務開發人員應該瞭解資料庫嗎？他們需要瞭解應用伺服器嗎？他們需要瞭解底層對象嗎？對於業務開發人員來說，採取哪一種方式最為直觀，或容易交流和掌握。（通常這種問題是無解的，每一種方案都由其優點和缺點，只能是找到一種折中的方法。）在回答這個問題之前先看看常用的三種設計思路。

關注資料或關注商務程序或關注介面

     討論這個話題會直接關係到我們的開發過程方法，也許還會影響到這個架構的架構模式。從本身這三點來說很容易讓我們想到三層架構，也許是他太根深蒂固的原因吧，但決不是我們唯一的選擇。

     如果從資料為主體展開設計，則資料就是主體，業務開發人員需要先設計資料庫，可以直接對原生態的資料進行控制、讀取。平台可以提供一種業務類代碼產生機制或運用現有的ORM產品。VS提供的強型別DataSet便是以這種方式設計的。開發人員可以很方便的根據資料庫中的表、視圖。產生對應的強型別的資料對象，一般來說一個資料庫標的欄位對應一個類的屬性，這也符合一般開發人員的思維模式，使他們很容易接受而且靈活的運用。一般的持久化工具都對此有強大的代碼產生支援。這種方法的缺點就是業務開發人員必須資料資料庫。而且總會誤導業務開發人員將資料庫中的表和具體的業務僅僅相連，業務對象在某種程度上很容易被架空。從而失去分層的意思。這種方法要運用的好資料庫設計便變的極為重要，資料庫設計者必須不僅熟練資料庫設計而且要深刻理解業務。在應對需求變更方面，這種方式也顯得有些無力。因為商務邏輯本身的複雜程度，不可能直接全部依靠產生的業務類代碼。再要從資料庫直接產生介面，那必然還需要在做大量的代碼工作，用友UAP提供了這種機制，但我覺得他的介面在很難在被自訂。

    以商務程序為主體展開設計，則業務對象就是主體。我們可以編寫可視化的業務對象產生工具，或者直接用VS提供的類別設計工具，或者運用程式碼片段來減少代碼的輸入。因為業務開發人員必須瞭解業務，所以對於設計業務類來說就是他們主要要做的事情。這樣平台可以根據業務類和指定的資料來源自動的產生資料庫，以及資料庫中的表。根據類與類之間的從屬關係產生資料庫的主外鍵關係。運用類的特性(attribute)和屬性(property)的特性(attribute)或者是用設定檔來制定類執行個體的各種介面視圖，從而提供與業務類直接產生介面的機制。為了不使靈活性除了平台提供的常用視圖外，使用者還可以自訂UI模版。以業務對象為主體的設計最大的缺點就是業務人員完全失去了對資料庫的控制，對於極其特殊的需求來說，如果平台不能給予一個良好的制止的話，可能是開發人員陷入僵局。而且對於報表的開發，不能完全使用資料庫本身所提供的強大的功能支援，對於平台開發人員來說提供一套自動的產生控制機制也不是一件易事，平台開發難度大大增加。XAF便是這樣設計的，很強大，而且他所做的已遠遠超出了我所能想象的。

   最後是以介面為主體的設計。原型設計法便是以這種思路出發，這種方式最容易和使用者進行溝通也是使用者最能理解的一種方式。但對於開發一個平台來說我真暫時想不出要怎麼運用它。傳說中這樣描寫。

//平台提供一種機制，介面設計者利用平台工具繪製出使用者介面。
//和業務開發人員協作，運用平台工具，為每一個頁面控制項
//的屬性設定具體的值。然後根據平台模組組態管理工具配置頁面上各種動作的具體控制類。

不好意思這個我還真沒想過，剛才想了一下怎麼讓平台根據介面設計者做的介面直接產生資料庫，以及業務控制碼。也許可以某種強大的控制項。

 

    今天先到這裡，隨著我的進一步的分析，在我們的思維完全發散以及取捨求證之後，我們不久就開始考慮架構層次的功能要求，以及選取一種合適的架構，然後進一步完善我們的設計。思維本身淩亂、錯字、錯句在所難免。原生態的思維呈現給大家，希望得到您的意見。