【IT168 专稿】

    近年来，我们从桌面逐步转向客户服务器、3级、n级，直至面向服务。虽然在此过程中许多东西发生了变化，但是也有许多习惯保留下来。这是因为人们通常对改变有一种抵触心理，而程序上的问题也经常导致这种结果。本文将对这些错误的做法进行讨论并给出可行的解决方案。

    本文从设计与架构的角度来构建一个n级系统，其重点不是代码。实现n级系统有许多方式，这只是其中的一种。希望本文能为那些正在构建系统的人提供帮助。

    问题的提出

    当你问任何一名开发人员：业务逻辑应该放在哪里，他都会回答：“当然是业务层。”

    当你再问他：你们公司的业务逻辑在哪里呀，他一定还会回答：“当然是业务层。”

    业务逻辑当然是在业务层。不仅是业务逻辑的部分，而是全部的业务逻辑都应该在业务层。阅读本文后，许多开发人员会认识到，他们曾经以为正确的这一观点，实际上却是错误的。

    术语

    有些术语的定义比较复杂，为了叙述方便，在本文中我先定义如下：

    级：当我使用级（Tier）这个词的时候，我指的是物理服务器，或者用于提高处理能力的一组物理服务器这样物理意义上的级。

    层：层（Layer）指的是系统中的过程或部署单元中的一个区域。同一级上可能存在多个层，但是通过远程调用技术可以很容易地将层从一个级移动到另一个级。

    问题的发展

    桌面

    在桌面应用中，业务逻辑与其它层共同存在于同一级中。由于没有区别层的需要，所以这些层通常都混合在一起，没有明显的界限。

    客户服务器

    在客户服务器系统中有两个级，因此至少需要实现两个层。在早期，通常把服务器视为远程数据库，也就是区分为应用（客户端）与存储（服务器）。通常所有的业务逻辑都保存在客户端，与用户界面等层混合在一起。

    但是，不久人们便发现这种方式会消耗太多的网络带宽，并且为了减少客户需要经常进行重新部署所带来的麻烦要把大部分业务逻辑从客户端剥离。由于这里只有两个层，因此业务逻辑的唯一去处就是服务器。从架构上来说，在客户服务器系统中服务器是一个理想的场所，但是使用数据库作为平台却不是个好主意。数据库是用于存取的，它们的扩展性能也是以此为基础。数据库里存储的流程语言是用来对SQL所无法完成的数据转换进行补充的。它们需要非常快的执行速度，并不是用于复杂的业务逻辑的。

    虽然如此，这也是没有办法的办法。因此，出于实用主义，业务逻辑就像是硬被塞进了小鞋里。在一个两级的环境中，这虽然不完美，但也可算是一种改进。

    3级

    随着客户服务器系统的问题越来越突出，3级的设计模式开始流行起来。当时最急切需要解决的问题是连接数的问题。虽然现在的数据库可以处理数以千计的同时连接，但在20世纪90年代，500左右的连接就足够让大多数据库不堪重负了。

    于是连接池技术开始受到欢迎，但是要在一个有许多不同的客户端的系统中实现连接池，就需要在客户端与服务器之间插入一个第三级。这个中间级就是后来的"中间级"。虽然在大部分情况下，当时只是用中间级处理连接池，但是由于各种开发语言（C++、VB等）的作用业务逻辑涌入中间级，很快被证实中间级是存放业务逻辑的非常好的位置。

    中间级还能为低带宽的客户提供更好的连接，因为数据库的直接连接通常需要一个低延迟的网络环境。