給我複雜的BO

最近在上有關UML的課程，雖然老師沒有明講，我覺得這是Test-driven或use case driven之類的方法。所謂「之類」是說都是使用Iterator 的開發方式、每個iterator都要經過測試、每次出品都是production的水準。學到的東西當然要拿來用在工作上啦，忽然問題產生了...
我目前負責處理的案子，使用JSF+Hibernate+Spring，層次架構是 managed bean-BO-DAO(HibernateDAOSupport)。Managed bean有再區分bean與model， bean負責action與navigation、model負責JSP元件資訊及變化。BO當然是指企業邏輯；DAO則是與資料庫的間接。

在課程裡有教導我們如何去撰寫use case。例如針對「查詢資料」這個use case來說，它的use case敘述是：

1.使用者輸入查詢條件
2.系統向資料庫取得資料
3.系統將資料回傳給使用者

或是針對「新增資料」這個use case來說，他的敘述可能如下：

1.使用者點選編輯按鈕
2.系統帶出資料輸入畫面
3.使用者填入輸入資料
4.使用者切換下拉選單
5.系統依使用者選擇變換另一個下拉選單
6.使用者點選儲存按鈕
7.系統將資料儲存到資料庫

這些use case都嘛是與UI互動操作的敘述。
再統計一下歷來的需求異動：

1.因業務異動，使用者選項多了一個，另一個下拉選單也有變動...
2.其他單位有需求，要在某資料表中多填入一個欄位資料
3.使用者不要權限控管，希望可以看到全部資料，或不要資料分類(原本選單選A類，系統只列出A類的資料...)

大部份的需求都至少都是展示層要變動。

再來看看分層檔案的size大小。 JSF managed bean約2.5M，BO約400多K，DAO約700多K，不是說企業邏輯是最重要的嗎?怎麼我寫的code好像都是在處理畫面?? 2.5M還不包含JSP呢。這就是我覺得的問題：我這系統的BO在幹嘛? 再仔細去看一下BO裡面的code，還真是簡單到不行，有時在BO裡的撰寫就更好笑：

public Collection qryBList(String condition) {
return dao.qryList(condition);
}

這樣看來分層似乎沒多大的作用。
後來想想，我負責的這個案子本來就本來大部份就是對資料庫做單純的CRUD，沒什麼企業邏輯，甚至使用者的需求會是：這張table要再新輸入一個欄位；而不是變動銷貨分派邏輯。如果是像「table要再新輸入一個欄位」這樣的需求變動，要改的話就是要從第一層改到第三層；也就是說當需求變動是「變動銷貨分派邏輯」時，這種責任區分的架構方式就很有用了。這樣在異動code時，至少DAO不會異動到。當然這也要看DAO是怎麼個設計方式。事實上我負責的這個案子，當遇到「要先從這張Table中取得這筆資料，如果這筆資料是怎樣就去用這個A值去查詢一張table，如果是B值就要去查詢另外一張table」這樣的需求時，因為connection resource的問題，就要將這個 if 的部份放在DAO中了。這也是我這個案子BO這麼簡單的另外一個原因。像這樣子的情況，如果將A值改成C值就是要在DAO中改了。像這樣之所以會將企業邏輯放在DAO的原因，我認為是因為我們的設計是一支作業撘配一支DAO卻存取多張Table；當有企業邏輯需要依判斷來存取不同的Table時就會發生這樣的情形了。(我是接維護案，當初設計者為何會設計成一支作業一張DAO的原因已經不可考)。

不過這延伸出另一個問題：這表示說我們常說3-tier，可是卻很少提及如何實作 (還是是我沒讀到?)。一般我們所說的3-tire就是指View/JSP-Business logic-DB 3層次。可是在責任分配上，資料的檢核是放在那一層?? 在JSP的領域中，提倡使用servlet，不過在實作上一些簡單的檢核都會放在client、JSP、JavaScript等當中；較複雜的、需要去存取資料庫的檢核才會放在.java的檔案當中去做檢核。好吧~ 假設我們將檢核的部份放在.java當中好了, 總算是讓business logic layer較豐富了一些;但好像還不是很豐富...?是不是還有什麼邏輯可以放在business logic layer了呢? 像「先去Table A找記錄R1，若找得到資料R1則依據R1的C1欄位為條件查詢值再去Table B查記錄R2」這樣的邏輯是不是要放在business logic layer中呢? 這算不算是business logic呢?還是只是「DB」logic, 所以要放在DAO中做?談到這, 這讓我覺得接下來的議題似乎是系統設計的問題-DB不是存放資料的地方, 不應該有邏輯判斷。

離題話: CRUD這已經是個常用的名詞了。如果會是常用的名詞，表示需求與使用量很高；因此我們必需再另外思考一下要如何快速的開發這一類的需求程式而且可以應付使用者需求變動...。