【IT168 技术文章】

    两层系统（图12）允许用户界面和应用程序代码直接访问数据库和网络存储的API。应用程序使用数据库中存储的数据模型，但是不需要在该模型之上建立逻辑模型。当开发中的系统是一个原型系统或者已经知道其生命周期较短，期间API不会发生变化的时候，两层应用程序是理想的。典型情形下，这种方式用于小型的应用程序，它们的开发成本和时间都很少。

图12.两层架构

    此外，两层系统对于面向组件的开发环境也有意义，这种方式用在特定组件的实现之中。组件接口提供了一个隔离层，与这种方式的后果相反。使用脚本语言建立的多数应用程序都属于这一类，因为这种情况下多架构层的开发可能非常麻烦，不切实际。

    最后，两层的方式将提供更好的性能，并减少控制资源锁定的机制的需求。尽管两层模型在处理多个并发用户使用应用程序方面的能力有些欠缺，但是它的简单性可能远远优于其它的选择。此外，通过向数据库应用程序添加通用的数据处理程序，常常能用数据存储过程来消除一些简单的共享数据的问题。

    随着数据库的发展，三层（Three-tier）应用程序已经很普通了。三层系统（图13）满足了执行的隔离的需求。它基本上对于存储/数据库层可能被修改的任何应用系统都是理想的。但是，这种技术的隔离并不仅限于数据库。它能够，并且应该用在任何不要求应用程序开发者，或更重要的应用程序维护人员对于最低层有详细的了解就能共享代码的环境。

 
图13.三层架构

    相当频繁的重复使用是一个主要的设计考虑因素，在这种情形下需要建立应用程序模型以允许它的一部分被多个用户界面查看组件重复使用。它有一个指导方针是，在应用程序需要相同数据的多个视图的任何时候，开发者应该考虑使用三层方式代替两层方式。

    从两层模型迁移到三层模型需要考虑的主要问题包括适当的网络资源的可用性和管理并发数据访问的加锁方案。

    作为越来越强调网络计算的结果，最近出现了一种新的趋势，就是四层系统（图14）。当应用程序层需要支持高级行为的时候，可以考虑四层系统。四层模型与三层模型相似，但是其应用程序层被分解为表现层和对话层。表现层呈现了应用程序模型的视图部分，以及被特定视图的操作所约束的应用程序逻辑。对话层处理表现组件之间的资源共享的问题，包括与潜在的分布式业务对象模型通讯。