牛人都喜歡一些複雜的業務邏輯，如大型的醫療系統，銀行金融系統，企業oa等系統所涉及的業務。（越複雜的業務越能體現技術？？？）暫且不考慮這些了，任何乙個業務都免不了需要對使用者輸入的資料進行驗證吧？請大家回想一下，你所涉及的系統，有哪個業務不需要與資料打交道？
軟體系統是以資料為核心的，那麼運算元據的是什麼？就是業務邏輯。那麼乙個相當重要的操作——資料驗證，它屬不屬於業務邏輯？
我們暫且也不考慮其是不是業務邏輯，我們將從軟體開發的架構上來思考一下應該把資料驗證放在哪個合適的位置，是放在控制層，還是放在業務邏輯層？
假設有這樣乙個需求，民政部門的結婚登記——只有符合要求的男人和女人才能結婚吧？這是不可質疑的，所以我們抽象出這樣幾個要點：
1、只有異性才能結婚，同性不能結婚；
2、男性必須達到22周歲，女性必須達到20周歲；
3、已婚男性不能再結婚，已婚女性不能再結婚（符合一夫一妻制）；離異當然是未婚處理。
在這裡，我們先假定這是乙個web應用程式，使用了struts2，需要定義action類。同樣先假定把資料驗證放到 service業務邏輯層，所以有如下**：
package com.wgs.service;
import com.wgs.pojo.person;
public class personservice
return false;
} /**
* 判斷是否符合結婚條件
* @param p
* @return 符合結婚條件返回true，否則返回false
*/public boolean canmarry(person p) else
} /**
* 相應的結婚判斷資訊
* @param p
* @return
*/public boolean marriedinfo(person p) else
} else if (p.getgender() == 'f') else
} return flag;
} /**
* 已經結婚資訊
* @param p
* @return
*/public boolean married(person p) else if (p.getgender() == 'f')
return false;
}}
假定有這樣乙個需求，現在我們需要把這個web應用程式能夠讓android手機客戶端訪問，那麼我們是不是要在android平台上設計一套具有良好使用者體驗的客戶端介面？如果我們的資料驗證**放在action中，那麼，我們得花多少心思從action中抽取資料驗證**放到android平台上！而將資料驗證單獨作為業務邏輯後，只要android平台上做好介面，設定相應的控制器直接呼叫資料驗證業務邏輯就可以了。這是很方便的一件事，程式設計師都喜歡這樣幹吧？
總結來說，這樣的架構具有靈活性，可維護性，可擴充套件性。
所以，我們應該考慮把資料驗證放到業務邏輯層。想想spring的aop，也是同樣的道理。這裡就不深究啦，去吃午飯吧。
業務邏輯處理
功能的實現，都是依靠業務邏輯來完成的，記得看過不能完成業務邏輯的程式設計師都不會成長的，確實是的，最近在完成業務邏輯的時候，程式的業務判斷有很多的，所以開始接觸，設計模式，看到來一些設計模式，看結合專案，確實是可以根據設計模式來改寫的，so，懂得設計模式可以快速的，寫好的 的。關於函式同步和非同步之...
業務邏輯漏洞
業務邏輯漏洞是一類特殊的安全漏洞，業務邏輯漏洞屬於設計漏洞而非實現漏洞，是業務邏輯設計不嚴謹導致的漏洞。大多數業務邏輯漏洞沒有明顯的攻擊特徵，難以通過漏洞掃瞄的方式發現，也難以通過安全裝置來防護。繞過驗證 主要指身份驗證體系設計存在缺陷，可以使用某些技術手段繞過驗證機制冒用他人身份。越權訪問 主要指...
業務邏輯設計
1.action設計 shfwpgdzlbdmanager.copy mannager裡面的相應方法 shfwpgdzlbd.getbdtpid 傳入的引數從哪獲取，型別應和mannager的方法需要的引數型別相同 2.manager設計 設計之前宣告物件 private shfwpgdzlbdda...