一個業務系統設計構想（一）

背景：

公司計劃明年自主研發一個軟體産品，公司有專人負責産品的策劃和需求，我負責這個産品的技術架構方面。

這個産品屬于一個典型的資訊系統，從目前策劃人員交給我的檔案中，可以看出，系統規模較大，整體技術難度不高，但是也存在一些技術問題需要解決。

一、基礎資料與單據需要有完全的自定義功能。即使用者可以根據自身需要對基礎資料和單據增删字段，字段類型包括基本的資料類型（字元串、日期、數值等），還包括基礎資料和單據的引用類型。

二、系統需要支援離線和線上兩種操作模式。對于離線操作模式，需要考慮資料同步和沖突的問題。

三、靈活的報表設計器。使用者或者實施人員可以自行定義需要的資料報表，報表的來源可以是SQL語句，也可以是通過系統預設的取數公式來定義。

等等。。其他的還沒考慮到。

解決辦法構思：

第一個問題：

     一般能想到的做法是這樣的，以基礎資料的自定義字段為例，建立一個字段描述表，每條記錄對應着基礎資料表的每個字段，界面呈現、儲存時先讀取字段描述表，根據字段描述表中的記錄動态生成SQL來讀寫基礎資料表。單據的情況大緻類似，隻是字段描述表要複雜得多。

     這樣的做法看似簡單易行，但也有很多的問題：

     1.從軟體設計的角度來說，缺少了領域模型，通常設計人員拿到需求之後，首先不是去設計資料庫，而是考慮領域模型的建構，上述做法完全回避了領域模型的建立，直接讓設計人員去設計資料庫結構。

     2.對于動态生成的SQL，難以保證其安全性，也将軟體産品綁定到特定的資料庫系統。

     3.靈活性。某些字段需要進行特殊的驗證或者需要根據其他的字段來計算得出。如果設計時沒有考慮到的驗證方式或計算方式，那麼在實施過程中，還需要開發人員增加相應的代碼。

     4.代碼的複雜性。我曾經在一個項目中嘗試使用上述方式，雖然項目最終驗收了，但是“通過字段描述來動态生成SQL”的代碼是驚人的複雜，維護的難度可想而知。

     為了避免項目中出現上述問題，我考慮采用以下方式實作：

     對于基礎資料和業務單據，都有相應的領域模型（實體類），為了解決領域模型在編譯後就固定不變的問題，可以将每個基礎資料和單據都放在單獨的程式集中，使用者在更改了基礎資料和業務單據後，系統根據使用者的定義，自動生成實體類的代碼和相應的描述檔案，使用者和實施人員是可以進行更改，然後編譯為相應的程式集。

     界面的呈現和資料儲存，界面上采用反射來實作。将來也有可能提供界面設計器之類的功能，将界面元素綁定到實體類的某個字段。

     以上的這些僅為個人想法，還不成熟，歡迎拍磚。如果有想應用到項目中的朋友歡迎交流。

轉載于:https://www.cnblogs.com/yiway/archive/2008/12/11/1352915.html