请问业务逻辑层到底应该写什么？

Question

很不明白业务逻辑层应该写什么，本人初学，不太明白，比如修改密码吧，我感觉业务逻辑层应该分两步。一，检测用户名和原密码。二，如果正确则插入新密码。这两步分别调用DAL层的两个方法。检测用户名和原密码的方法和登录应该是一个。但我看到很多源码是把这两步合并到一个存储过程里了，以至于我认为存储过程更像业务逻辑层。我认为DAL和存储过程应该不牵扯具体业务逻辑啊，像上面的例子，如更新密码的存储过程就是更新密码，它不应该检测用户名和原密码。
检测用户名和密码是另一存储过程，它和登录所用的应该是一个。
买的书里一本书一个不同的做法，我直接迷糊了，请问各位到底是怎么写，就以修改密码为例好了。谢谢大家了！

Answer 1

修改密码来说，当然业务逻辑的服务就是修改密码。业务逻辑层的每一个功能其实对应的就是系统分析的一个用例，而不管什么数据库表操作。假设一个membership管理系统中经过你的分析设计，有12个用例，针对3种用户角色。或许经过一年发布，最终可以被20个不同的客户端系统的150个子程序过程调用，那么这12个用例就是业务逻辑层的发布形态，而那150个子程序过程就是表现层的与业务逻辑层通讯的对应物。作为一个系统服务的设计师，它会基于一个行业范围，考虑千奇百怪并且不断出新的各种客户端可能如何使用统一的业务逻辑层rpc调用接口，考虑需要发布什么实体和功能，考虑何时逐步开发一些服务。这就是作为业务逻辑层设计师所要考虑的事情。

Answer 2

大多数学生在学校学的，就是小OA软件那一套“开发”方法，就是调用关系数据库的客户端驱动、使用ADO.NET围绕十几个数据库表为核心（加上另外一些辅助表）做出千篇一律的“增删改查”的十几个“交互界面”，唯一有点技术含量的就是弄个稍微漂亮一点的下拉菜单、设计一下菜单权限分配。这类软件就是小OA，号称“管理企业”其实最终也就是企业里派几个人负责录入手工帐然后打印个报表而已，还能干什么呢？既不是好用的个人软件，也不是真正好用的企业业务操作软件。

Answer 3

你可以看出什么时候会更加注重业务逻辑层！至少，越是有点想做出个“平台”的战略雏形来的时候，而且通讯技术、终端驱动开发也不是一点不灵光的时候，不仅仅搞点OA开发而且可以搞点上点规模的硬件系统集成的时候，就需要推出不一样格局的产品思路了。而这时候，业务逻辑层设计是最稳定的核心。有些公司甚至没有很稳定不变的产品，因为很多公司的低级开发人员往往随便就撂挑子走人，可是只要一个公司有比较成熟的业务逻辑设计并且不遗余力地支持一些前端Demo程序，它也可以签下不错的销售单子来，有了钱再去招聘那些会一点数据库编程的人做什么DAL开发。