034子產品間關聯關系的優化的思路
前台的各種自定義控件都是為了展示資料和操作資料，作為管理系統的顔面固然重要，但是背景的控制系統默默的為前台提供資料和完成操作任務則更為重要。本自定義系統的核心部分是如何處理子產品的關聯關系。由于我一直做一些中小型的政府管理軟體，子產品間樹形關系比較明确，是以現在系統中的子產品間的關系的處理隻能是中規中矩的樹形。比如我最早的一個部落格裡面舉例的一個“銷售系統”的業務子產品如下圖所示。
在上面的圖中，11個子產品的關聯關系很直覺，沒有交叉，每一個子產品隻有單獨的用處，層次關系清晰。現在的自定義系統對于這種關聯關系的處理已經很好了。但是随着業務需求的深入，子產品間的關聯關系會更加複雜化。比如“訂單”子產品需要增加一個“發貨倉庫”的關聯，發貨倉庫又有所屬“市”的屬性；再給“訂單“增加“始發地市”和”目的地市“的關聯，如下圖所示：
上圖的這個子產品間的結構複雜了不少，主要是出現了非正常樹的形狀。在上一張圖裡，“市”子產品其實就隻能定義為“客戶機關的市”，但是在這張圖表裡，“市”子產品就同時要擔任4個角色。“省”子產品同樣也是。對于權限控制來說，最主要的改變是：在上一張圖裡如果設定一個角色，隻能檢視江蘇省的客戶的資訊，那麼在省的子產品上建立一個規則即可，是沒有問題的。在下面的圖裡就有了問題了，如果把權限的值設在“省”上面，那麼這個省到底對子子產品要怎麼控制呢？你是要檢視江蘇省的客戶，還是江蘇省的商品倉庫，還是始發地是江蘇的，還是目的地的江蘇的呢？ 現在的系統不能直接處理上圖的子產品結構，但是有一個變通的辦法，就是建立4個市和4個省的影子子產品，即要建立 商品倉庫市、始發地市、目的地市、客戶機關市，對于省份來說也要建立相應的4個省來對應。這個方法可以解決問題，但是在系統裡面要多出8個bean檔案，如果省市用在很多的子產品上，那麼會增加更多的bean檔案。這個方法對于比較複雜的系統來說是行不通的。 鑒于以上的一些問題和實際的需求，需要對子產品間的關聯關系來重新設計，使其能夠按照上圖的關聯結構來處理好各個子產品的關系。上圖顯示的一共是12個子產品，但是真正管理的應該有12－2+8＝18個子產品。在處理訂單的父子產品“市”和“省”的時候，必須按照不同的條線将其理順。 要将上圖的子產品關聯關系生成如下圖的正常樹就好處理了。在系統中市和省仍舊隻有一個bean，但是在處理關聯關系的時候，必須厘清是哪一個市或省。
在上圖，可以明顯的看清“訂單”子產品具有4個省和4個市，這樣我們在設定權限的時候，或者在設定導航屬性的時候，就可以指定是哪一個省份了。 在系統的内部處理上面，“省份”對“訂單”就有4條線路可以達到。 1.省－市－客戶機關； 2.省－市－商品倉庫； 3､省－市（始發地）; 4、省－市（目的地市）; 同樣的，省份對應“訂單明細”子產品，也有這四條路徑可以走。
在綜合查詢的時候，可以設定為“客戶機關省”、“商品倉庫省”、“始發地省”、“目的地省”設定不同的查詢條件，在分數的時候，還可以按這4種類型的省份來分類彙總。想想功能真是可以無限擴充。
要完成能夠解析上圖這樣的子產品間的關聯關系，必須在底層進行重構了。需要重新設計子產品的關聯關系的定義，包括資料讀取、導航、綜合查詢等等一系列的子產品。這将是一個非常複雜的工作。