业务逻辑层与储存过程的疑惑
很惭愧，做了两年的软件开发，那些业务逻辑该放在业务逻辑层，哪些业务逻辑该用存储过程来实现，心里一直是一团浆糊。从大学开始，我就对SQL语句有着说不出的讨厌，所以我对数据库技术知之甚少，所以要实现某个功能，首先想到的就是抽象业务流程，设计接口，抽象类型，提取核心流程做基础设计，最后才考虑数据的存储，所以我建表几乎是从来不考虑满足那个什么三范式的。类型到数据表的相互映射，也是中规中矩的自己造轮子，利用特性、反射，从不用成熟的ORM框架。
因为做的项目较小，数据处理也不是很多，所以上述做法也行得通，而且自我感觉良好。但是我最近仔细思考了我做过的项目，几乎所有的业务都是对数据的处理，归根结底还是对数据的枚举和对数据的修改。数据库的存储工作不是能以最好的性能满足对数据的枚举和对数据的修改么？而且存储过程的优点很多：
- 减少网络带宽,按理论存储过程会提高性能.
- 无需重新编译,更改后即可运行,无需重新编译代码
- 由专门的dba写的sql语句更高效
- 安全性(在传输用户名密码时,可防止注入等情况)
后来的几个项目我又改变了风格，纯粹用存储过程来开发，中间的业务逻辑层几乎纯粹成了数据传递层，完全抛弃了模型类和场景类，从前端到后台都是DataTable过来过去，中间用了微软的强类型表。项目也照样完成得很好，而且速度奇快。当然，存储过程也有他的缺点：
- 依赖于数据库厂商,难以移植(当一个小系统发展到大系统时,对数据库的要求也会发生改变)
- 业务逻辑大的时候,封装性不够,难调试难以维护
- 复杂的应用用存储过程来实现，就把业务处理的负担压在数据库服务器上了。没有办法通过中间层来灵活分担负载和压力.均衡负载等
但我们又有多少项目需要移植数据库呢，又有多少业务逻辑是存储过程解决不了呢，又有多少项目是让数据库系统满负荷运行呢？可能我是菜鸟，但我做的几十个项目中，真的极少遇到上述的情况。
两厢对比，迷糊了，晕菜了，我潜意识里知道存储过程实现所有的业务是不好的，而且存储过程的IDE没有“重构”“查找所有引用”这样贴心的小功能，维护确实很恼火。但我又说不出这东西究竟差在那些大地方，求园子里面的达人指点指点呀，你们的业务逻辑是如何在业务逻辑层实现的呀，求解惑……
最后，帮公司发个招聘启示：
成都九洲电子信息是一家有军工背景的企业，在物联网、 RFID方面有核心竞争力，现在因为项目需要，大量招聘 .Net开发人员，月薪4000-8000。详情请见：
