進入詳細設計階段後的乙個重要任務是對業務方法進行設計，如果業務邏輯是封裝到事務指令碼方法中的，那就簡單得多了，即根據介面可設計得到事務指令碼業務方法。很多事情都是說起來容易，做起來難，下面我結合乙個簡單的例項，說明業務方法的設計過程。
一、先貼出介面原型設計圖，具體操作圖中已經標註得非常清楚了，我不再描述。
二、根據介面原型，建立簡單的域模型，如下圖：
（注：其中的分頁物件，是根據介面原型，在設計模型中加入的）
三、業務方法設計過程是我說明的重點
我們最先遇到的問題，應該是業務物件粒度的確定，常見的有兩種方法，一種是根據功能模組來劃分，另一種是根據用例來劃分，如果你仔細想想就會發現，這兩種劃分方式都是從邏輯上對業務方法進行歸類，總的原則是：有利於實現以及後期的維護。如果業務類粒度太細，業務類過多，會加大實現及管理上的複雜性；如果粒度過粗，乙個業務類中業務方法過多，邏輯相關性不強，也會大了實現和維護難度。
對介面原型分析後，我們基本上可以確定兩個業務類（當然是用介面定義的），乙個是選單相關的，乙個是與學生相關的（如果再細一點，也可以把班級相關的抽出來）。
1、imenuservice
從上面僅有的需求看，登入成功後我們要展示乙個樹型結構的選單，而選單設計為一對多自關聯，所以，我們設計了下面的乙個方法：+ getmemnubylevel(level : int) : list，即根據選單級別，得到這個級別選單的集合，在實現的時候，需要取到所有的頂級選單，通過jstl的迴圈標記取出子選單並顯示(當然，具體實現時你可能還要動動腦筋)。
2、istudentservice
這是本例中的核心。有人說業務方法命名無非就是一些crud的操作，但我認為，業務方法在命名上應該具更有業務含義，而不僅僅是一些簡單的crud，比如：changepassword，login，register，pay，sendmail等等，這些方法都具有明確的業務含義。以有明確業務含義來為業務方法命名可以作為業務方法設計的乙個標準，話又說回來，在實際專案中，還是有70%以上的業務方法命名是具有明顯的crud含義的，還是來看看具體的設計吧。
a、首先看到的第乙個介面是登入介面，介面中有兩個輸入字段：學號及密碼，登入成功後進入主介面，系統應該在作用域中儲存使用者的狀態資訊，登入有可能會失敗，基於這個需求，設計業務方法如下：
+ login(code : string, password : string) : student，返回值為student將作為狀態資訊儲存，這個方法會throws loginexception異常，這個異常是自定義的。
在這個方法的設計中，也有人把code與password封裝在乙個studnet物件中傳遞，看起來就像這樣+ login(s: student) : student，我個人覺得這種設計就沒有第一種方式來得直觀。
loginexception也可以不定義，通過返回值student是否為null，檢測登入的執**況，但我更傾向於業務層丟擲統一的異常的做法。
b、學生的分頁查詢。分頁查詢功能有兩個地方可以觸發，乙個是：選單中的「學生資訊一覽表」，乙個是主介面中的「查詢」按鈕，但主介面中是帶查詢條件的，那我們是設計乙個方法還是設計兩個方法呢（我倒是見過不少初學者設計兩個方法的哦）？答案是統一成乙個，方法簽名為+ getstudentsbypage(pageno : int, pagesize : int, studentexample : student) : page。
在上面的方法中，我們在studentexample封裝了多個查詢條件（我也見過一些初入門的程式設計師把每個條件都單傳的設計，條件多了的話方法引數會非常龐大），後期用qbe實現，我會用一篇文章單獨介紹這種多條件的具體實現方法。
c、主介面的查詢中會出現班級列表的選擇，提供+ getallclasses() : list就可搞定，但前提是班級不是太多，如果班級非常多，這種設計就有問題了，介面原型設計出得改。
d、新增學生。方法為+ addstudent(studnet : student) : void，這個方法寫出來又有人提出疑問：你的方法返回void，那儲存失敗怎麼辦？很顯示，提出這樣問題的人對異常機制沒有理解透，要去好好看書了哦。
新增學生的時候，我們要會對學號（業務主鍵）的惟一性進行檢測（使用ajax或儲存時的檢測），因此，還要提供乙個業務方法+ getstudnetbycode(code : string) : student來做這件事。
e、修改學生資訊。很明顯，實現步驟是先查詢後修改，因此設計了下面兩個方法：+ getstudnetbyid(id : long) : student根據id查詢學生，+ updatestudent(studnet : student) : void儲存學生資訊。
f、刪除學生資訊。步驟也是先查後刪除，查詢的方法前面已經設計了+ getstudnetbyid(id : long) : student，我們僅設計乙個刪除方法+ deletestudentbyid(student: student) : void。
也有人設計成這樣+ deletestudentbyid(id : long) : void，即根據id來刪除乙個學員，當然底層實現也是先查後刪除，這樣的設計也是非常不錯的，把查詢物件的過程都封裝到業務類實現中，而不用在 action中進行查詢，效率會有一點點的提公升，我推薦這種設計。
g、批量刪除。可以設計為+ deletestudentbyids(ids : long) : void，也可以在action中通過for迴圈呼叫+ deletestudentbyid(id : long) : void實現，根據你個人喜好自行設計。或都也可以設計成根據物件集合刪除，即傳入乙個collection。
h、檢視學生資訊。+ getstudnetbyid(id : long) : student就可以實現，這個方法我們前面已經設計好了。
最終詳細設計業務方法如下圖：
從以上的分析過程可以發現，我們的業務方法設計完全是依賴於介面原型一點一點「扣」出來的，業務有增刪或變化，業務方法進行相應的調整，這種按用例或模組確定業務方法粒度並依據介面原型確定、分配業務方法的過程比較直觀，也比較簡單，業務實現採用事務指令碼模式，事務指令碼為何在目前的web應用開發中如此流行，與設計過程簡單化是息息有關的。掌握了上面這個例子中的業務方法設計，你已經可以勝任軟體開發了。
後面的文章中，我會用乙個更簡單的例子，結合軟體開發流程講，講解整個實現過程（包括關鍵部分的偽**），我努力寫成乙個對於初級程式設計師來說最好的基礎教程。
App介面原型設計工具
首先，一款優秀的 支援移動端演示 隨時隨地演示給boss，廁所 食堂 電梯 以體現我是那麼的敬業 長點工資必備 元件庫 高效復用，誰用誰知道 可以快速生成全域性流程 程式猿看不懂拆解的，給丫的看這個 手勢操作 轉場動畫 互動特效 這些都不需要，留給專業的互動 視覺，搞那麼虛的不如多想想產品流程邏輯做...
軟體介面原型設計工具 Web Axure RP
如果你覺得balsamiq mockups賣79美元還貴的話，那axure就更顯得色差奢侈了，很多axure的培訓費都遠高於這個價！axure的發音是 ack sure rp則是 rapid prototyping 快速原型的縮寫。axure rp pro是美國axure software solu...
軟體介面原型設計工具 Web Axure RP
分享一下我老師大神的人工智慧教程！零基礎，通俗易懂！如果你覺得balsamiq mockups賣79美元還貴的話，那axure就更顯得色差奢侈了，很多axure的培訓費都遠高於這個價！axure的發音是 ack sure rp則是 rapid prototyping 快速原型的縮寫。axure rp...