https://segmentfault.com/q/1010000000251484
我的觀點：這么設計的目的並不能方便隨時修改業務邏輯，只是方便熟悉存儲過程的開發人員，能夠隨時修改業務邏輯。對於后續的業務邏輯越趨於復雜，修改就越困難，存儲過程中的重復代碼就越多；重復代碼越多，系統的壞味道就越散發開來。
由於.net在一些系統UI展示控件上，跟數據庫集成，非常方便用戶開發，簡單的拖拖拉拉，再鏈接數據庫，就能搞出一些像樣的東西出來。這對系統邏輯不是很復雜的情況下，開發簡單高效，且由於邏輯不是很復雜，也容易維護，所以很有優勢。
但是系統的邏輯一旦達到一定的復雜度，把業務邏輯都放在存儲過程中就會有2個很大的弊端，一是把系統的壓力全都壓到數據庫上，這樣勢必增加系統的風險，且針對將來的負載增加的時候，不容易做水平擴展；二是業務邏輯放到存儲過程，維護比較困難，且對於一些業務擴展，勢必會增加冗余的代碼，這樣也會增加系統出bug的風險。
所以，在考量一個設計方案的時候，要綜合系統的復雜度、技術實現平台等各方面。例如，對於技術實現平台，.net提供了這種集成數據庫的UI控件，能夠有效實現數據驅動，開發簡單高效，但java就無法提供這種優勢(ps:一般把這種叫做【表模塊】設計方式)；對於系統復雜度很高，為了應付后續的需求，一般會考慮【領域模型】設計方式，通過對業務進行領域建模，利用面向對象的各種設計模式，能夠有效滿足業務需求，且將系統壓力分流到應用端，通過應用端的水平擴展，更方便系統擴容。
由於不了解你們系統的業務復雜程度，所以也不能說現有的基於存儲過程的設計方式有什么問題，這需要你根據你們系統的需求等各方面綜合來評估。最后推薦一本書：企業應用架構模式