五层逻辑构架设计.docxVIP

五层逻辑构架设计 Rockfor d Lhotka 译者：张子阳 jimmy_dev@163.com 出处：《Expert C# Business Objects, Second Edition》一书 第一章 术语表 逻辑：Logical 物理：Physical 构架：Architecture 框架：Framework 表现层：Presentation 用户界面：User Interface 业务逻辑：Business Logic 数据访问：Data Access 数据和存储管理：Data and Storage Management 图形用户接口：Graphical User Interface 胖客户端：Richer Client-side 智能客户端：Smart Client 应用程序：Application 服务器端控件：Server-side control 事件驱动：Event-driven 可重用组件：Reusable component 用户控件：User Control 元数据驱动：Metadata-driven 对象关系映射：object-relational mapping 本文将探讨 5 层逻辑构架的程序设计。这种类型的构架一旦建立成功，就可以配置成适用于各种各样的物理构架，从而为Windows 窗体、Web 窗体、Web 服务提供最佳的服务。 这种构架由 图 1 所示的五部分构成： 表现层用户界面业务逻辑数据访问数据和存储管理 表现层 用户界面 业务逻辑 数据访问 数据和存储管理 图 1. 五层逻辑构架 应该时刻记得使用 N 层逻辑构架的好处是将功能清楚地划分成角色或者组，以便提升程序的可读性和可维护性。下面我们来仔细的定义一下这几个层的功能。 表现层 首先，可能你很想知道为什么我会将表现层从用户界面层分离出去。的确，从 Windows 应用程序的角度来看，表现层和用户界面是一回事：它们都是些可以与用户进行交互的图形用户接口。 然而从 Web 程序的角度来看(或者从一个基于终端的程序来看)，区别应该是很明显的。典型地， 浏览器仅仅是将内容显示给用户，并采集用户的输入信息。在这种情况下，所有实际的交互逻辑―― 产生内容输出或者分析用户输入的代码――都在 Web 服务器端运行(或者主框架中)，而不是在客户端机器上。 当然，在现实环境中，浏览器可能会运行 JavaScript 脚本或者是胖客户端代码。但是，这些代码都是不可信任的(译注：可以联想下客户端表单验证)。这些代码必须被视为与你运行于服务器端的代码进行交互的独立代码。所以，即使有代码运行于浏览器中，你的应用程序的用户界面代码仍然是运行于 Web 服务器上的。 应该了解到，当前讨论的逻辑构架必须同时支持智能客户端和基于 Web 的客户端(甚至是更多其他受到一些限制的客户端，比如说手机或者其他移动设备)，在很多情况下，意识到表现层必须在物理上与用户界面逻辑分离是很重要的。为了能实现这种分离，设计程序时就很有必要围绕着这个主题来进行。 注意： 注意：表现层的技术类型是非常多的，并且每个都会伴随一个新的、相对不兼容的、我们必须使用的技术。实际上，不可能创建一个完全从表现层抽象出来的程序框架。正因为如此，构架和框架将仅仅是支持不同的表现层，而不是自动创建它们。所以，我们将把注意力主要集中在简化构架中的其他层，这些层中的技术相对稳定一些。 用户界面 之前我已经讲述了表现层和用户界面之间的区别，那么后者的目的现在应该已经很清楚了。这一层的程序逻辑决定了用户看到什么、导航的路径以及如何处理用户的输入。在一个 Windows 应用程序中，这些是置于表单之后的代码。实际上，这些也是在 Web 应用程序中置于表单之后的代码，但是，在这种情况下，用户界面层也包含服务器端控件中的代码。从逻辑上来讲，这属于同一层的不同部分。 在很多应用程序中，用户界面代码非常复杂。首先，它必须对于用户非流线型的请求做出响应(很难控制用户是否点击控件，进入或离开一个表单或者页面)。用户界面代码还必须在逻辑上与业务层进行交互，以验证用户输入、执行任何需要进行的任务，或者做任何与业务层相关的功能。 基本上，用户界面层的目的是编写接受用户输入然后提供输入信息到业务逻辑层的代码，这些用户输入信息在业务逻辑层中被验证、处理或者进行其他任何的操作。用户界面层必须对用户的请求做出响应，显示与业务逻辑层交互所产生的结果。用户输入的数值正确么？如果不正确，那么是哪里除 了问题？等等。 在.Net 中，用户界面几乎总是事件驱动的。Windows 窗体总是在用户输入或者点击表单项时做出相应，Web 窗体总是在一次用户动作的客户端/服务器往返中对事件做出响应。尽管 Windows 窗体和 Web 窗体技术大