https://segmentfault.com/q/1010000000251484
我的观点：这么设计的目的并不能方便随时修改业务逻辑，只是方便熟悉存储过程的开发人员，能够随时修改业务逻辑。对于后续的业务逻辑越趋于复杂，修改就越困难，存储过程中的重复代码就越多；重复代码越多，系统的坏味道就越散发开来。
由于.net在一些系统UI展示控件上，跟数据库集成，非常方便用户开发，简单的拖拖拉拉，再链接数据库，就能搞出一些像样的东西出来。这对系统逻辑不是很复杂的情况下，开发简单高效，且由于逻辑不是很复杂，也容易维护，所以很有优势。
但是系统的逻辑一旦达到一定的复杂度，把业务逻辑都放在存储过程中就会有2个很大的弊端，一是把系统的压力全都压到数据库上，这样势必增加系统的风险，且针对将来的负载增加的时候，不容易做水平扩展；二是业务逻辑放到存储过程，维护比较困难，且对于一些业务扩展，势必会增加冗余的代码，这样也会增加系统出bug的风险。
所以，在考量一个设计方案的时候，要综合系统的复杂度、技术实现平台等各方面。例如，对于技术实现平台，.net提供了这种集成数据库的UI控件，能够有效实现数据驱动，开发简单高效，但java就无法提供这种优势(ps:一般把这种叫做【表模块】设计方式)；对于系统复杂度很高，为了应付后续的需求，一般会考虑【领域模型】设计方式，通过对业务进行领域建模，利用面向对象的各种设计模式，能够有效满足业务需求，且将系统压力分流到应用端，通过应用端的水平扩展，更方便系统扩容。
由于不了解你们系统的业务复杂程度，所以也不能说现有的基于存储过程的设计方式有什么问题，这需要你根据你们系统的需求等各方面综合来评估。最后推荐一本书：企业应用架构模式