现在的系统
客户服务器
在客户服务器系统中业务逻辑通常会被分成客户端与服务器两部分。
当然实际比例会根据应用和企业有所不同。为了使业务逻辑集中，许多业务逻辑是在存储过程和视图中实现的。然而许多业务规则由于与用户界面有关，因此无法简单地通过SQL或存储过程实现，或者说在客户端上执行的速度更快。由于这些原因，业务规则被分到了客户与服务器两端。
N级
N级系统的情况更为糟糕（更多具体原因我会在下面讲述）。它不但没有让系统更稳固，反而使业务逻辑变得更为分散。
当然由于业务逻辑的分布不同，各个系统也不相同，但是有一点是一样的。业务逻辑分布在三层上，而不是两层。下面是几个实例。
案例1
典型的N级系统通常是这样的：
这种情况下，业务层没有包含任何业务规则。这不是一个真正的业务层，它只是一个数据库结果的XML格式化程序和匹配程序。虽然这也有一定的优势，但它毕竟不是一个真正的逻辑层。把它看作一个没有业务层的物理层更好一些。
案例2
另一种情况如下：
通常会有一部分应用规则被转移到了业务层，但是原来在数据库中的那部分仍然留在了那里。
在这种设计中，当对业务层进行重用的时候，必须对应用中的业务逻辑进行复制。这违背了实现业务层的最基本原则。
这种应用可能会违背或者忽略业务规则。真正的业务层决不会这样。
集中
取而代之的是业务层应该包含所有的业务规则。
这种设计有以下优势：
· 所有业务逻辑都在一个位置，可以方便地进行验证、修改、调试。
· 可以使用真正的开发语言实现业务规则。这种语言比SQL和存储过程更灵活且更适合于业务规则。
· 数据库变成一个存储层，可以有效地进行存取数据操作。
这种情况才是我们的目标。但是由于某些原因（特别是验证）我们需要在客户端作一些复本。这些规则应该获得业务层的支持。还有，在某些系统中，为了实现一些较极端的性能优势可能会把一些重要的规则放在数据库中。因此，一个更为现实的方式应该是下面的样子。请注意业务层仍然包含100%的业务规则，其它的只是为了实现特殊目的的复本。
