应用程序结构：概念视图-8应用程序（企业结构）

最新推荐文章于 2022-06-19 19:45:45 发布

colayungnew

最新推荐文章于 2022-06-19 19:45:45 发布

阅读量1.4k

点赞数

分类专栏： Design Patterns MSDN 文章标签：数据库 microsoft 存储 asp.net ui 任务

本文链接：https://blog.csdn.net/colayungnew/article/details/178420

版权

Design Patterns 同时被 2 个专栏收录

43 篇文章 1 订阅

订阅专栏

MSDN

38 篇文章 0 订阅

订阅专栏

本页内容

	业务服务
	剖析业务服务
	用户接口处理
	概念上的应用程序结构
	应用程序小结

业务服务

在基于服务的体系结构中，应用程序由处理服务（请参阅处理）以及实现业务功能和用户接口 (UI) 的更基本的服务组成。

在剖析业务服务时，您将看到它的体系结构与下面图 1 介绍的处理中所描述的体系结构非常类似。不同之处在于下图已用组件将服务替换。

但是，请注意以下几点：

•	与组件相比，较松的耦合对于服务来说更为重要；组件允许使用较为紧密的耦合。这意味着，根据粒度的要求，您可以适当放宽上述讨论的使用处理服务的准则。对于较细粒度的功能，通过解耦将会削弱优势。
•	处理组件可以共享原子事务处理，从而极大简化了业务服务当中的处理设计。
•	组件可以直接调用；而且不需要明确的消息传送。从而简化了异常情况的处理过程。

图 1.

返回页首

剖析业务服务

这一部分对业务服务进行了讨论。业务服务可以创建作为多层系统。典型的业务服务由以下四层的组合构成：

•	服务接口。服务接口公开了将被外部世界看到的功能。添加接口不仅更易于公开明确的服务接口，从而为履行协定提供了方便，而且更易于隐藏服务中设计为供内部使用的接口。
•	业务处理层。业务处理层负责控制业务处理；它按照步骤定义业务处理，除了组装业务逻辑层的请求之外，它并不执行任何数据操作。
•	业务实体层。业务实体层负责执行需要完成的任务；它负责实现处理的各个步骤。通常使用业务实体来设计该层。业务实体实现业务规则，并不存储业务数据，但是可以保持对存储数据的数据实体的引用。
•	数据表示层。数据表示层以便于业务逻辑层使用的形式保留数据。该层只拥有关于数据操作的通用逻辑，并不包含有关业务域的具体知识。数据表示层使用数据访问器来存储数据。它通常使用存储过程来执行以下操作：在数据库和这些访问器之间来回传输数据，以及反映数据库布局和数据访问器之间结构的区别；从而无需更改代码即可自由变换数据库的设计，并且无需更改表即可自由改变内部数据表示形式。

这种可选视图如图 2 所示。

图 2. 业务服务中的分层

将业务规则与内部数据表示分离开可以充分利用数据库使用数据的能力，同时无需复制逻辑即可隔离规则。例如，需要使用按客户姓名排序的定单列表时，数据库将提供获取该列表的有效方法。请求的处理流程如下：首先依次通过接口和处理层，然后直接通过业务逻辑层，最后进入数据表示层。该层将用公式表述对数据库的请求，并生成内部数据表示。现在无需再做进一步操作即可将响应直接返回请求方。

数据的内部表示不必与数据库的布局保持相同；存储过程用于反映两者之间的差别。并且内部表示也不必与向外部世界公开的格式保持一致。可以计算其他一些信息，并将这些信息添加到外部结构中；也可以筛选一些私人信息。有时，可能需要公开多种格式，以满足组织中不同角色的需求或满足对这些角色的访问限制要求。

图 3 解释了服务如何以松散方式耦合紧密耦合的系统。

图 3. 以松散方式耦合紧密耦合的系统

服务结构完全用于以松散方式耦合紧密耦合系统。虽然它的设计目标并不是紧密耦合服务中的组件，但是优秀的设计结果通常是服务中的组件紧密耦合。

返回页首

用户接口处理

用户接口处理向业务处理提供类似功能，但是它们使用用户接口服务，而不是业务服务。

系统的用户接口 (UI) 由执行一些任务（如从用户那里请求信息或将信息传递到用户）的服务或组件组成。这些服务可能以 Microsoft Windows 窗体或 ASP.NET 控件这样的技术实现，这些技术是便于以后重用的理想候选技术。您可以使用一个处理来控制用户接口元素之间的交互，以将操作管理从用户接口元素的核心业务功能中分离出来。

图 4 解释了这一过程的实现方式。