业务逻辑在一个系统中可放的地方很多，有的人选择放在存储过程中，有的人会选择放在业务组件中，这些方式都可以进行业务逻辑的判断。既然提供了这些方式都可以实现业务逻辑的判断，就证明它们存在的合理性。就像在设计的过程中，很多人会将进行条件选择语句封装到不同的类的重构，以满足设计中的”开－闭“原则，这样做有他的道理。但并不是说以后就不用条件转移语句了，要不开发语言怎么会支持条件转移语法呢。我们要根据具体的情况选择是否重构，比如我们只需要创建一个对象，如果进行重构，试想得建多少的类啊，维护起来头不够大啊。
那是不是在项目开发中就可以任选一种方式呢？当然是不可取，很多都是依据具体情况而定的，只有在具体情况中才能说好还是不好。打个比方，一个项目，好的设计需要1个月，差的设计只要10天，此时你应该选择哪一个？更多的人会选择花1个月的设计，因为大家对设计的追求。但是如果这个项目只给了1个月时间，你又该如何选择呢？当然，这个例子不是很确切，但只想说明一点：适合才是正确的。将业务写入存储过程，可以找出很多的理由推翻这种做法，也能找很多的理由赞成这种做法，那都是站在不同的项目环境看这个问题。对于小型的项目，逻辑相对简单，为了快速，减少开发规模，将业务逻辑写入存储过程，是比较好的一种方式；对于大型项目，考虑业务逻辑的复杂性，将业务逻辑封装到组件中是一种相对较好的方式。相对存储过程的修改、维护和部署，是否要更安全和方便呢？同时，将业务逻辑写入存储过程，会增加数据库服务器的负荷，极端一点有一个很复杂的逻辑，需要读取很多的数据进行比较，很多人并发访问，那我们是否应该考虑一下数据库服务器的负担，是否可以将一部分工作放在客户端或者应用服务端？。要说的太多了，不过要说明的还是一点：适合才是正确的！
那是不是在项目开发中就可以任选一种方式呢？当然是不可取，很多都是依据具体情况而定的，只有在具体情况中才能说好还是不好。打个比方，一个项目，好的设计需要1个月，差的设计只要10天，此时你应该选择哪一个？更多的人会选择花1个月的设计，因为大家对设计的追求。但是如果这个项目只给了1个月时间，你又该如何选择呢？当然，这个例子不是很确切，但只想说明一点：适合才是正确的。将业务写入存储过程，可以找出很多的理由推翻这种做法，也能找很多的理由赞成这种做法，那都是站在不同的项目环境看这个问题。对于小型的项目，逻辑相对简单，为了快速，减少开发规模，将业务逻辑写入存储过程，是比较好的一种方式；对于大型项目，考虑业务逻辑的复杂性，将业务逻辑封装到组件中是一种相对较好的方式。相对存储过程的修改、维护和部署，是否要更安全和方便呢？同时，将业务逻辑写入存储过程，会增加数据库服务器的负荷，极端一点有一个很复杂的逻辑，需要读取很多的数据进行比较，很多人并发访问，那我们是否应该考虑一下数据库服务器的负担，是否可以将一部分工作放在客户端或者应用服务端？。要说的太多了，不过要说明的还是一点：适合才是正确的！
Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=1504043
