企业应用架构模式

　　《企业应用架构模式》作者是当今面向对象软件开发的专业，他在一组专家级合作者的帮助下，将40多种经常出现的解决方案转化成模式，终写成这本能够应用于任何一种企业应用平台的、关于解决方案的、不可或缺的手册。《企业应用架构模式》获得了2003年度美国软件开发杂志图书类的生产效率奖和读者选择奖。《企业应用架构模式》分为两大部分。一部分是关于如何开发企业应用的简单介绍。第二部分是《企业应用架构模式》的主体，是关于模式的详细参考手册，每个模式都给出使用方法和实现信息，并配以详细的Java代码或C#代码示例。此外，整《企业应用架构模式》中还用了大量UML图来进一步阐明有关概念。
　　《企业应用架构模式》是为致力于设计和构建企业应用的软件架构师、设计人员和编程人员而写的，同时也可作为高等院校计算机专业及软件学院相关课程的参考教材。

　　

　　企业应用开发的实践得益于多种新技术的出现，多层的面向对象平台（如Java、.NET）已经日渐平常。这些新工具和新技术有能力构建更强大的企业应用程序，但是在实现上还不太容易。由于开发人员未能充分理解有经验的对象程序开发人员在架构方面的经验和教训.因此企业应用中经常存在一些共同的错误。
　　《企业应用架构模式》就是面向企业应用开发者的，可帮助他们迎接这种艰难挑战。《企业应用架构模式》的作者Ma riin Fowler注意到，尽管技术本身存在变化——从Smalltalk到

　　我虽然没有从事过早期批处理系统时期的任何工作，但我认为当时的软件工作人员不会太关注层次的概念，只要编写操作某些文件（ISAM、VSAM等）格式的程序，这就是当时的应用。它不需要层次。

　　20世纪90年代，随着客户／服务器系统的出现，分层的概念更明显了。这样的系统是一种两个层次的系统：客户端包括用户界面和其他应用代码，服务器端通常是关系型数据库。常见的客户端工具如VB、PowerBuilder和Delphi。这些工具使得构建数据密集型应用非常容易。因为它们的用户界面控件通常都是SQL感知的。因此，可以通过将控件拖拽到“设计区域”来建立界面，然后再使用属性表单把控件连接到后台数据库。

　　如果应用仅仅包括关系数据的简单显示和修改，那么这种客户／服务器系统的工作方式非常合适。问题来自领域逻辑：如业务规则、验证、计算等。通常，人们会把它们写在客户端，但是这样很笨拙，并且往往把领域逻辑直接嵌入到用户界面。随着领域逻辑的不断复杂化，这些代码将越来越难以使用。而且，这样做很容易产生冗余代码，这意味着简单的变化都会导致要在很多界面中寻找相似代码。

　　另外一种办法是把这些领域逻辑放到数据库端，作为存储过程。但是，存储过程只提供有限的结构化机制，这将再次导致笨拙的代码。而且，很多人喜欢关系型数据库的原因之一是SQL是一个标准，允许他们更换数据库厂商。尽管真正更换数据库厂商的用户寥寥无几，但还是有很多人希望拥有这种选择，并且没有太大的附加代价。由于存储过程都是数据库厂商私有的，因此普通用户被剥夺了这种选择权。

　　在客户／服务器方式逐渐大众化的同时，面向对象方式开始崛起。面向对象为领域逻辑的问题找到了答案：转到三层架构的系统。在这种方式下，在表现层实现用户界面，在领域层实现领域逻辑，在数据源层存取数据。这种方式使你可以将复杂的领域逻辑从界面代码中抽取出来，单独放到中间层，用对象加以建模和组织。

 　　……