适合才是正确的 之 “关于业务逻辑加入存储过程”

          业务逻辑在一个系统中可放的地方很多，有的人选择放在存储过程中，有的人会选择放在业务组件中，这些方式都可以进行业务逻辑的判断。既然提供了这些方式都可以实现业务逻辑的判断，就证明它们存在的合理性。就像在设计的过程中，很多人会将进行条件选择语句封装到不同的类的重构，以满足设计中的”开－闭“原则，这样做有他的道理。但并不是说以后就不用条件转移语句了，要不开发语言怎么会支持条件转移语法呢。我们要根据具体的情况选择是否重构，比如我们只需要创建一个对象，如果进行重构，试想得建多少的类啊，维护起来头不够大啊。

          那是不是在项目开发中就可以任选一种方式呢？当然是不可取，很多都是依据具体情况而定的，只有在具体情况中才能说好还是不好。打个比方，一个项目，好的设计需要1个月，差的设计只要10天，此时你应该选择哪一个？更多的人会选择花1个月的设计，因为大家对设计的追求。但是如果这个项目只给了1个月时间，你又该如何选择呢？当然，这个例子不是很确切，但只想说明一点：适合才是正确的。将业务写入存储过程，可以找出很多的理由推翻这种做法，也能找很多的理由赞成这种做法，那都是站在不同的项目环境看这个问题。对于小型的项目，逻辑相对简单，为了快速，减少开发规模，将业务逻辑写入存储过程，是比较好的一种方式；对于大型项目，考虑业务逻辑的复杂性，将业务逻辑封装到组件中是一种相对较好的方式。相对存储过程的修改、维护和部署，是否要更安全和方便呢？同时，将业务逻辑写入存储过程，会增加数据库服务器的负荷，极端一点有一个很复杂的逻辑，需要读取很多的数据进行比较，很多人并发访问，那我们是否应该考虑一下数据库服务器的负担，是否可以将一部分工作放在客户端或者应用服务端？。要说的太多了，不过要说明的还是一点：适合才是正确的！

Windows DNA 应用程序通常使用以下三种实现方式中的一种或多种方式来实现其业务逻辑：

•

ASP 页

•

COM 组件，可能使用 COM+ 提供的其他服务

•

在 DBMS 中运行的存储过程

一般来讲，在 ASP 页中编写过多的业务逻辑并不是一个好办法。因为必须使用简单的语言（例如，Microsoft Visual Basic? Script (VBScript)），而且每次执行时都要解释代码，这会对性能造成影响。而且 ASP 页中的代码不好维护，主要是因为业务逻辑通常与创建用户界面的表示代码混合在一起。

鉴于这种情况，建议在编写中间层业务逻辑时，将业务逻辑当作 COM 对象来实现。这种方法比编写纯粹的 ASP 应用程序要稍微复杂一点，但是可以使用全功能语言来生成编译好的可执行文件，因此其结果要快得多。将业务逻辑包装在 COM 对象中还可以将此代码与包含在 ASP 页中的表示代码完全分隔开来，从而使应用程序更易于维护。

从 COM 到 COM+，其体系结构相差无几。但是，正如许多 Windows DNA 体系结构设计人员所了解的，除非真正需要，否则不应使用 COM+ 提供的核心服务，如事务、实时 (JIT) 激活、基于角色的安全性和线程服务等。使用其他开发平台提供的 COM+ 或类似服务自然会导致应用程序速度更慢、更复杂。只有在以下情况下使用 COM+ 才有意义：

•

需要跨越不同资源管理器（例如，Microsoft SQL Server(TM) 和 Oracle）的分布式事务。

•

应用程序可以有效地利用基于角色的安全性。

•

可以增强 Microsoft Visual Basic? 6.0 的线程特性。

•

JIT 激活能够提高性能；浏览器客户端很少出现这种情况，因为 ASP 页是通过 JIT 有效激活的。

•

COM+ 的配置优势大大简化了应用程序的部署。

编写业务逻辑的第三种方式是，创建一些作为存储过程在数据库管理系统 (DBMS) 中运行的代码。尽管使用存储过程的主要原因是将数据库架构的详细信息与业务逻辑分隔开以简化代码的管理和提高安全性，但代码与数据如此接近也有助于优化性能。那些必须独立于 DBMS 的应用程序（例如由独立的软件供应商创建的应用程序）通常要避免使用这种方法，因为它会将应用程序锁定到某个特定的数据库系统中。存储过程的编写和调试可能会比 COM 对象的编写和调试难，而且此方法会减少重复使用代码的机会，这是因为 COM 对象通常比存储过程更易于重复使用。但是大多数自定义应用程序仍然连接到最初创建它们的 DBMS 上，因此使用存储过程的性能优势还是很大的。鉴于这种情况，那些必须尽可能运行良好的 Windows DNA 应用程序通常对部分或全部的业务逻辑都使用存储过程。