面向对象的应用服务层设计

前言

  N层的应用软件系统,由于其众多的优点,已经成为典型的软件系统架构,也已经为广大开发人员所熟知。在一个典型的三层应用软件系统中,应用系统通常被划分成以下三个层次:数据库层、应用服务层和用户界面层。如下图所示:

其中,应用服务层集中了系统的业务逻辑的处理,因此,可以说是应用软件系统中的核心部分。软件系统的健壮性、灵活性、可重用性、可升级性和可维护性,在很大程度上取决于应用服务层的设计。因此,如何构建一个良好架构的应用服务层,是应用软件开发者需要着重解决的问题。

  为了使应用服务层的设计达到最好的效果,我们通常还需要对应用服务层作进一步的职能分析和层次细分。很多开发者在构建应用服务层的时候,把数据库操纵、业务逻辑处理甚至界面显示夹杂在一起,或者,把业务逻辑处理等同于数据库操纵,等等,这些,都是有缺陷的做法。本文,就在这个方面进行设计时可采用的方案进行一些探讨。

设计的原则和评判标准

  同软件工程的原则一样,应用服务层的设计,必须遵循的最重要的原则就是高内聚和低耦合。软件分层的本来目的,就是提高软件的可维护性和可重用性,而高内聚和低耦合正是达成这一目标必须遵循的原则。尽量降低系统各个部分之间的耦合度,是应用服务层设计中需要重点考虑的问题。

  内聚和耦合,包含了横向和纵向的关系。功能内聚和数据耦合,是我们需要达成的目标。横向的内聚和耦合,通常体现在系统的各个模块、类之间的关系,而纵向的耦合,体现在系统的各个层次之间的关系。

  系统的框架,通常包含了一系列规范、约定和支撑类库、服务。

  对于如何判断一个软件的系统框架的优劣,笔者认为,可以从以下几个方面来评判:

  ◆ 系统的内聚和耦合度

  这是保证一个系统的架构是否符合软件工程原则的首要标准。

  ◆ 层次的清晰和简洁性

  系统每个部分完成功能和目标必须是明确的,同样的功能,应该只在一个地方实现。如果某个功能可以在系统不同的地方实现,那么,将会给后来的开发和维护带来问题。

  系统应该简单明了,过于复杂的系统架构,会带来不必要的成本和维护难度。在尽可能的情况下,一个部分应该完成一个单独并且完整的功能。

  ◆ 易于实现性

  如果系统架构的实现非常困难,甚至超出团队现有的技术能力,那么,团队不得不花很多的精力用于架构的开发,这对于整个项目来说,可能会得不偿失。简单就是美。

  ◆ 可升级和可扩充性

  一个系统框架,受设计时技术条件的限制,或者设计者本人对系统认识的局限,可能不会考虑到今后所有的变化。但是,系统必须为将来可能的变化做好准备,能够在今后,在目前已有的基础上进行演进,但不会影响原有的应用。接口技术,是在这个方面普遍应用的技巧。

  ◆ 是否有利于团队合作开发

  一个好的系统架构,不仅仅只是从技术的角度来看,而且,它还应该适用于团队开发模型,可以方便一个开发团队中各个不同角色的互相协作。例如,将Web页面和业务逻辑组件分开,可是使页面设计人员和程序员的工作分开来同步进行而不会互相影响。

  ◆ 性能

  性能对于软件系统来说是很重要的,但是,有的时候,为了能让系统得到更大的灵活性,可能不得不在性能和其他方面取得平衡。另外一个方面,由于硬件技术的飞速发展和价格的下降,性能的问题往往可以通过使用使用更好的硬件来获得提升。

  应用服务层的内容

  应用服务层,通常也被称为业务逻辑层,因为这一层,是应用软件系统业务逻辑处理集中的部分。然而,我将这一层称为应用服务层,而不称业务逻辑层,因为,这一层需要处理的不仅仅是业务逻辑,还包含了其他方面的内容。

  从完整的角度来说,应用服务层需要处理以下内容:

  ◆ 数据的表示方式

  数据,是软件处理的对象。从某种程度上来说,"软件,就是数据结构加算法"的说法,是有一定意义的。在面向对象的系统中,数据是用类来表示的,代表了现实世界实体对象在软件系统中的抽象。考虑所谓的MVC模式,这个部分的类属于M--实体类的范畴。由于应用软件通常会使用数据库,数据库中的数据,可以看成是对象的持久化保存。由于数据库一般是关系型的,因此,这个部分,还需要考虑类(对象)同关系型数据的映射,即通常所说的O-R MAP问题。

  ◆ 数据的存取方式

  如同上述所说,软件系统处理的实体对象数据需要持久化保存数据库中,因此,我们必须处理系统同数据库的交互,以及数据的存取和转换方式的问题。

  ◆ 业务逻辑的组织方式

  在面向对象的系统中,业务逻辑表现为对象之间的交互。有了上述的实体对象,以及对象的保存策略,就可以将这些对象组合起来,编写我们的业务逻辑处理程序。在业务逻辑的处理中,必须保证处理的正确性和完整性,这将会涉及到事务处理。通常,我们也会把业务逻辑封装成组件的形式,以得到最大的可重用性。

  ◆ 业务服务的提供方式

  在我们完成系统的功能后,如何向客户提供服务,是我们需要考虑的问题。这里的客户,不仅仅是指软件的使用者,也包括调用的界面、其他程序等。例如,在一个基于Web的ASP.Net或JSP系统中,业务逻辑功能的客户便是这些ASP.Net页面或JSP页面。业务逻辑组件应该通过什么方式,直接的,或间接的,向这些客户提供服务,是这一层需要完成的任务。

  ◆ 层的部署和层间交互

  对于一个多层的应用软件系统来说,尤其是大型的应用软件系统,通常需要把不同的部分部署在不同的逻辑或物理设备上。特别是一些基于Web的应用软件系统,其部署工作将涉及到Web服务器、组件服务器、数据库服务器等不同的服务设备。在进行应用软件架构的设计的时候,必须考虑各种不同的部署方案。

  综上所述,一个完整的基于Web的应用软件系统,其架构可以用下图来表示(Websharp推荐的应用软件系统架构):

  对于以上各个方面来说,每个问题都可以有很多种策略和方案,但是,在一个系统中,应该尽可能的统一这些策略和方案。也就是说,在一个系统,或者一个项目中,应该统一每个解决每个问题所采用的方法。软件的开发方法是灵活的,可以用不同的方法解决相同的问题,这会诱使开发人员采用他们认为能够表现自己的方法,但是,从整个系统来看,这将会是灾难性的。我们应该尽可能统一,就是,采用统一的数据表示方式、统一的数据存取方式、统一的业务逻辑处理方式等。

时间: 2024-10-16 10:17:06

面向对象的应用服务层设计的相关文章

面向对象编程6大设计原则:单一职责原则

单一职责原则(Single  Responsibility Principle)简称SRP原则. 定义 应该有且仅有一个原因引起类的变更. 优点 可以降低类的复杂度,一个类只负责一项职责,其逻辑肯定要比负责多项职责简单的多: 提高类的可读性,提高系统的可维护性: 变更引起的风险降低,变更是必然的,如果单一职责原则遵守的好,当修改一个功能时,可以显著降低对其他功能的影响. 说明 单一职责原则不只是面向对象编程思想所特有的,只要是模块化的程序设计,都适用单一职责原则: 单一职责原则要根据项目的实际情

UML和模式应用:面向对象的分析与设计

1.1.什么是分析和设计 分析(analysis):强调的是对问题和需求的调查研究,而不是解决方案,即应该如何使用系统,系统应该具有哪些功能. 设计(design):强调的是满足需求的概念上的解决方案(在软件和硬件方面),而不是其实现.最终,分析可以实现,而实现则表达了真实和完整的设计. 分析和设计一词最好加以限制,如面向对象的设计.数据库设计. 有益的分析和设计可以概括为:做正确的事(分析)和正确地做事(设计). 1.2.什么是面向对象的分析和设计 在面向对象分析(OOA)过程中,强调的是在问

面向对象技术的软件设计

面向对象技术(Object-Oriented Technology).面向对象技术强调在软件开发过程中面向客观世界或问题域中的事物,采用人类在认识客观世界的过程中普遍运用的思维方法,直观.自然地描述客观世界中的有关事物.面向对象技术的基本特征主要有抽象性.封装性.继承性和多态性. 对象模型化技术(OMT) 对象模型化技术把分析时收集的信息构造在三类模型中,即对象模型,功能模型和动态模型 对象模型:最关键的模型,描述系统的静态结构,包括构成系统的类和对象,以及他们之间的关系 在对象模型化技术中,类

面向对象的七个设计原则

一.单一职责原则 一个类,最好只做一件事,只有一个引起它的变化.单一职责原则可以看做是低耦合.高内聚在面向对象原则上的引申, 将职责定义为引起变化的原因,以提高内聚性来减少引起变化的原因.职责过多,可能引起它变化的原因就越多,这将 导致职责依赖,相互之间就产生影响,从而大大损伤其内聚性和耦合度.通常意义下的单一职责,就是指只有一种单一 功能,不要为类实现过多的功能点,以保证实体只有一个引起它变化的原因.专注,是一个人优良的品质:同样的,单 一也是一个类的优良设计.交杂不清的职责将使得代码看起来特

面向对象编程的软件设计原则

在開始Android软件实际APP開始之前,我们须要对面向对象设计原则及设计模式做一个初步的了解.才干在以后的实战过程中,少走弯路.使我们的软件开发生涯感觉到快乐.轻松.好了,废话少说,咱们今天给大家一起探讨一下软OOP中的软件开发设计原则.这些东东都是OOP的设计精髓,他们蕴藏着前辈留下的产物.眼下.软件设计最基本原则有下面几种(总共同拥有11种):单一职责原则.开放封闭原则.依赖倒置原则.接口隔离原则和里氏替换(Liskov替换)原则 单一职责原则 就是一个类值做一件事情.引起它发生变化的仅

UML和模式应用-1面向对象的分析与设计

1.本书的主要内容 UML和面向对象的思想 对应用了UML和模式的面向对象分析与设计(OOA/D)的介绍 重点阐述对象设计,也会讲述在OOA/D中如何使用UML OOD的原则和模式 职责驱动设计 模式,问题解决方案公式 案例研究 贯穿全书的案例研究 用例 讲述需求分析 迭代开发 迭代开发使用统一过程(UP)的敏捷方法作为示例迭代过程来讲述迭代开发 TODO

用面向对象的思维方式来设计数据库

场景 我们有多种类型订单:实物订单.特享商户订单.核销订单.生活缴费订单.电影票订单.机票订单.以及以后会持续新增的未知类型订单,它们都存放在不同的订单类型表中 影响 导致有些业务做起来会比较痛苦 比如: 统计当前用户未付款订单总数 在列表中显示当前用户在某个时间段内所有未支付订单的信息(实现方式如上) 例外还会有个未知因素:持续新增的未知类型订单 每新增一种内型订单,上面的实现都将随之新增业务代码.各种蛋疼. 思路 上次换工作,面试遇到一道面试题,如下: "请设计数据库,用来存放 老师.学生等

面向对象的七种设计原则

下面的截图:主要讲述了七种设计原则定名称,定义以及使用的频率. ? 原则一:(SRP:Single responsibility principle)单一职责原则又称单一功能原则 核心:解耦和增强内聚性(高内聚,低耦合) 描述: 类被修改的几率很大,因此应该专注于单一的功能.如果你把多个功能放在同一个类中,功能之间就形成了关联, 改变其中一个功能,有可能中止另一个功能,这时就需要新一轮的测试来避免可能出现的问题. 原则二:开闭原则(OCP:Open Closed Principle) 核心思想:

设计模式<面向对象的常用七大设计原则>

面向对象设计的目标之一在于支持可维护性复用,一方面需要实现设计方案或者源码的重用,另一方面要确保系统能够易于扩展和修改,具有较好的灵活性. 常用的设计原则有七个原则: 1.单一职责原则(single responsibility principle,SPR) 一个类只负责一个功能领域中的相应职责.(或者可以定义为:就一个类而言,只有一个原因能够引起它变换). 单一职责原则是实现高内聚.低耦合的指导方针,是最简单的也是最难运用的原则. class Chart { private String ty