软件开发层次的简单了解.doc

1、 1 / 5简述三层架构和两层架构:三 层 架 构 (3-tier application) 通 常 意 义 上 的 三 层 架 构 就 是 将 整 个 业 务 应 用 划 分 为 ： 表现 层 （ UI） 、 业 务 逻 辑 层 （ BLL） 、 数 据 访 问 层 （ DAL） 。 区 分 层 次 的 目 的 即 为 了 “高 内聚 ， 低 耦 合 ”的 思 想 。 、 表 现 层 （ UI） ： 通 俗 讲 就 是 展 现 给 用 户 的 界 面 ， 即 用 户 在 使 用 一 个 系 统 的 时 候 他的 所 见 所 得 。 、 业 务 逻 辑 层 （ BLL） ： 针 对 具 体 问

2、 题 的 操 作 ， 也 可 以 说 是 对 数 据 层 的 操 作 ， 对 数据 业 务 逻 辑 处 理 。 、 数 据 访 问 层 （ DAL） ： 该 层 所 做 事 务 直 接 操 作 数 据 库 ， 针 对 数 据 的 增 添 、 删 除 、修 改 、 更 新 、 查 找 等 。三 层 架 构概 述三层架构(3-tier application) 一个三层架构的应用程序由三部分组成，这三部分各自分布在网络中的不同地方。这三个部分分别是：工作站或表示层接口、事务逻辑、数据库以及与其相关的程序设计。在 软 件 体 系 架 构 设 计 中 ， 分 层 式 结 构 是 最 常 见 ， 也 是

3、 最 重 要 的 一 种 结 构 。 微 软 推 荐 的分 层 式 结 构 一 般 分 为 三 层 ， 从 下 至 上 分 别 为 ： 数 据 访 问 层 、 业 务 逻 辑 层 （ 又 或 称 为 领 域 层 ）、 表 示 层 。这种应用程序的设计使用客户/服务器模式，各层可以同时开发，并且可以由不同的程序员组用不同的语言来开发。因为各个层次的开发不会影响其他层次，所以这种模型对于进一步开发软件是很方便的。例如：2 / 5老张去饭馆，先跟服务生要菜单看，这就是表述层，再跟服务生点菜，服务拿着菜单去交给后台大厨，这就是业务逻辑层，大厨做好菜再让服务生拿上来，这就是数据访问层三 层 结 构 原

4、理 ：3 个 层 次 中 ， 系 统 主 要 功 能 和 业 务 逻 辑 都 在 业 务 逻 辑 层 进 行 处 理 。所 谓 三 层 体 系 结 构 ， 是 在 客 户 端 与 数 据 库 之 间 加 入 了 一 个 “中 间 层 ”， 也 叫 组 件 层 。这 里 所 说 的 三 层 体 系 ， 不 是 指 物 理 上 的 三 层 ， 不 是 简 单 地 放 置 三 台 机 器 就 是 三 层 体 系 结 构 ，也 不 仅 仅 有 B/S 应 用 才 是 三 层 体 系 结 构 ， 三 层 是 指 逻 辑 上 的 三 层 ， 即 使 这 三 个 层 放 置 到 一台 机 器 上 。三 层

5、体 系 的 应 用 程 序 将 业 务 规 则 、 数 据 访 问 、 合 法 性 校 验 等 工 作 放 到 了 中 间 层 进 行 处理 。 通 常 情 况 下 ， 客 户 端 不 直 接 与 数 据 库 进 行 交 互 ， 而 是 通 过 COM/DCOM 通 讯 与 中 间层 建 立 连 接 ， 再 经 由 中 间 层 与 数 据 库 进 行 交 互 。表 示 层表 示 层 （ User Interface） :位 于 最 外 层 （ 最 上 层 ） ， 离 用 户 最 近 。 用 于 显 示 数 据 和接 收 用 户 输 入 的 数 据 ， 为 用 户 提 供 一 种 交 互 式 操

6、 作 的 界 面 。业 务 逻 辑 层业 务 逻 辑 层 （ Business Logic Layer） ： 无 疑 是 系 统 架 构 中 体 现 核 心 价 值 的 部 分 。它 的 关 注 点 主 要 集 中 在 业 务 规 则 的 制 定 、 业 务 流 程 的 实 现 等 与 业 务 需 求 有 关 的 系 统 设 计 ，也 即 是 说 它 是 与 系 统 所 应 对 的 领 域 （ Domain） 逻 辑 有 关 ， 很 多 时 候 ， 也 将 业 务 逻 辑 层 称为 领 域 层 。 例 如 Martin Fowler 在 Patterns of Enterprise Appli

7、cation Architecture 一 书 中 ， 将 整 个 架 构 分 为 三 个 主 要 的 层 ： 表 示 层 、 领 域 层 和 数 据 源 层 。 作为 领 域 驱 动 设 计 的 先 驱 Eric Evans， 对 业 务 逻 辑 层 作 了 更 细 致 地 划 分 ， 细 分 为 应 用 层 与 领域 层 ， 通 过 分 层 进 一 步 将 领 域 逻 辑 与 领 域 逻 辑 的 解 决 方 案 分 离 。业 务 逻 辑 层 在 体 系 架 构 中 的 位 置 很 关 键 ， 它 处 于 数 据 访 问 层 与 表 示 层 中 间 ， 起 到 了 数据 交 换 中 承 上

8、启 下 的 作 用 。 由 于 层 是 一 种 弱 耦 合 结 构 ， 层 与 层 之 间 的 依 赖 是 向 下 的 ， 底 层对 于 上 层 而 言 是 “无 知 ”的 ， 改 变 上 层 的 设 计 对 于 其 调 用 的 底 层 而 言 没 有 任 何 影 响 。 如 果在 分 层 设 计 时 ， 遵 循 了 面 向 接 口 设 计 的 思 想 ， 那 么 这 种 向 下 的 依 赖 也 应 该 是 一 种 弱 依 赖 关系 。 因 而 在 不 改 变 接 口 定 义 的 前 提 下 ， 理 想 的 分 层 式 架 构 ， 应 该 是 一 个 支 持 可 抽 取 、 可 替换 的 “抽

9、 屉 ”式 架 构 。 正 因 为 如 此 ， 业 务 逻 辑 层 的 设 计 对 于 一 个 支 持 可 扩 展 的 架 构 尤 为 关键 ， 因 为 它 扮 演 了 两 个 不 同 的 角 色 。 对 于 数 据 访 问 层 而 言 ， 它 是 调 用 者 ； 对 于 表 示 层 而 言 ，它 却 是 被 调 用 者 。 依 赖 与 被 依 赖 的 关 系 都 纠 结 在 业 务 逻 辑 层 上 ， 如 何 实 现 依 赖 关 系 的 解 耦 ，则 是 除 了 实 现 业 务 逻 辑 之 外 留 给 设 计 师 的 任 务 。数 据 层3 / 5数 据 访 问 层 （ Data Acces

10、s Logic） ： 有 时 候 也 称 为 是 持 久 层 ， 其 功 能 主 要 是 负 责 数据 库 的 访 问 ， 可 以 访 问 数 据 库 系 统 、 二 进 制 文 件 、 文 本 文 档 或 是 XML 文 档 。简 单 的 说 法 就 是 实 现 对 数 据 表 的 Select， Insert， Update， Delete 的 操 作 。 如 果 要加 入 ORM 的 元 素 ， 那 么 就 会 包 括 对 象 和 数 据 表 之 间 的 mapping， 以 及 对 象 实 体 的 持 久化 。 概括来说，分层式设计可以达至如下目的：分散关注、松散耦合、逻辑复用、标准定

11、义。所以:一个好的分层式结构，可以使得开发人员的分工更加明确。一旦定义好各层次之间的接口，负责不同逻辑设计的开发人员就可以分散关注，齐头并进。例如 UI 人员只需考虑用户界面的体验与操作，领域的设计人员可以仅关注业务逻辑的设计，而数据库设计人员也不必为繁琐的用户交互而头疼了。每个开发人员的任务得到了确认，开发进度就可以迅速的提高。松散耦合的好处是显而易见的。如果一个系统没有分层，那么各自的逻辑都紧紧纠缠在一起，彼此间相互依赖，谁都是不可替换的。一旦发生改变，则牵一发而动全身，对项目的影响极为严重。降低层与层间的依赖性，既可以良好地保证未来的可扩展，在复用性上也是优势明显。每个功能模块一旦定义好

12、统一的接口，就可以被各个模块所调用，而不用为相同的功能进行重复地开发。进行好的分层式结构设计，标准也是必不可少的。只有在一定程度的标准化基础上，这个系统才是可扩展的，可替换的。而层与层之间的通信也必然保证了接口的标准化。如果是一个考试系统，考试合格的最低分数线要改，只需要修改业务逻辑相对应函数就可以了，只要此函数的入口参数和返回内容不变，在客户端不需作任何改动。在这里，看到了面向对象编程的特性之一封装性的优点，而这一点在开发大型应用时尤其有用，可以把开发人员分成两组，一组负责开发界面层，另一组负责开发商业逻辑层，双方只要按照事先商定的函数接口，并行地开发就可以，而不必向从前那样，后面的工作必须

13、等前面的工作完成后才能开始。当然，这样的开发模式需要很好的项目协调和文档作支持。例如：如果现在用的系统是 SQL SERVER 数据库，由于各种原因要更改用 ORACLE。如果不是三层结构系统的话，可能需要改很多代码，延长了开发周期。现在使用了三层结构，只要在加一个 Oracle 的数据访问层。这样就可以实现多数据库了。再例如：现在可能要做另外一个系统了，该系统也要对数据库进行操作。如果以前编写过，这样的一个数据层。只要把以前写的那个数据层拷贝过来就可以了。实现代码复用。从而减短了软件的开发周期了。优 缺 点优 点 ：4 / 51、 开 发 人 员 可 以 只 关 注 整 个 结 构 中 的

14、其 中 某 一 层 ； 2、 可 以 很 容 易 的 用 新 的 实 现 来 替 换 原有 层 次 的 实 现 ； 3、 可 以 降 低 层 与 层 之 间 的 依 赖 ； 4、 有 利 于 标 准 化 ； 5、 利 于 各 层 逻 辑 的复 用 。缺 点 ：1、 降 低 了 系 统 的 性 能 。 这 是 不 言 而 喻 的 。 如 果 不 采 用 分 层 式 结 构 ， 很 多 业 务 可 以 直 接 造访 数 据 库 ， 以 此 获 取 相 应 的 数 据 ， 如 今 却 必 须 通 过 中 间 层 来 完 成 。 2、 有 时 会 导 致 级 联 的修 改 。 这 种 修 改 尤 其

15、体 现 在 自 上 而 下 的 方 向 。 如 果 在 表 示 层 中 需 要 增 加 一 个 功 能 ， 为 保 证其 设 计 符 合 分 层 式 结 构 ， 可 能 需 要 在 相 应 的 业 务 逻 辑 层 和 数 据 访 问 层 中 都 增 加 相 应 的 代 码 。规 则三 层 结 构 的 程 序 不 是 说 把 项 目 分 成 WebUI,DAL, BLL 三 个 模 块 就 叫 三 层 了 , 下 面 几 个问 题 在 你 的 项 目 里 面 ： （ 先 看 一 下 四 个 条 件 ）1. UILayer（ User Interface Layer） 里 面 只 有 少 量 (或

16、 者 没 有 )的 SQL 语 句 或 者 存 储过 程 调 用 , 并 且 这 些 语 句 保 证 不 会 修 改 数 据 ?2. 如 果 把 UILayer 拿 掉 , 你 的 项 目 还 能 在 Interface/API 的 层 次 上 提 供 所 有 功 能 吗 ?3. 你 的 DAL(Data Access Layer)可 以 移 植 到 其 他 类 似 环 境 的 项 目 吗 ? 4. 三 个 模 块 , 可 以 分 别 运 行 于 不 同 的 服 务 器 吗 ? 如 果 不 是 所 有 答 案 都 为 YES, 那 么 你 的 项 目 还 不 能 算 是 严 格 意 义 上 的

17、 三 层 程 序 . 三 层 程序 有 一 些 需 要 约 定 遵 守 的 规 则 ：1. 最 关 键 的 , UI 层 只 能 作 为 一 个 外 壳 , 不 能 包 含 任 何 BizLogic 的 处 理 过 程2. 设 计 时 应 该 从 BLL 出 发 , 而 不 是 UI 出 发 . BLL 层 在 API 上 应 该 实 现 所 有 BizLogic, 以 面 向 对 象 的 方 式3. 不 管 数 据 层 是 一 个 简 单 的 SqlHelper 也 好 , 还 是 带 有 Mapping 过 的 Classes 也 好 , 应 该 在 一 定 的 抽 象 程 度 上 做 到

18、 系 统 无 关4. 不 管 使 用 COM+(Enterprise Service), 还 是 Remoting, 还 是 WebService 之 类的 远 程 对 象 技 术 , 不 管 部 署 的 时 候 是 不 是 真 的 分 别 部 署 到 不 同 的 服 务 器 上 , 最 起 码 在 设 计 的时 候 要 做 这 样 的 考 虑 , 更 远 的 , 还 得 考 虑 多 台 服 务 器 通 过 负 载 均 衡 作 集 群所 以 考 虑 一 个 项 目 是 不 是 应 该 应 用 三 层 /多 层 设 计 时 , 先 得 考 虑 下 是 不 是 真 的 需 要 ? 实际 上 大 部

19、 分 程 序 就 开 个 WebApplication 就 足 够 了 , 完 全 没 必 要 作 的 这 么 复 杂 . 而 多 层 结构 , 是 用 于 解 决 真 正 复 杂 的 项 目 需 求 的 。 与 MVC 的 区 别MVC（ 模 型 Model-视 图 View-控 制 器 Controller） 是 一 种 设 计 模 式 ， 我 们 可 以 用 它来 创 建 在 域 对 象 和 UI 表 示 层 对 象 之 间 的 区 分 。5 / 5同 样 是 架 构 级 别 的 ， 相 同 的 地 方 在 于 他 们 都 有 一 个 表 现 层 ， 但 是 他 们 不 同 的 地 方

20、在 于其 他 的 两 个 层 。在 三 层 架 构 中 没 有 定 义 Controller 的 概 念 。 这 是 我 认 为 最 不 同 的 地 方 。 而 MVC 也 没有 把 业 务 的 逻 辑 访 问 看 成 两 个 层 ， 这 是 采 用 三 层 架 构 或 MVC 搭 建 程 序 最 主 要 的 区 别 。 当然 了 。 在 三 层 中 也 提 到 了 Model， 但 是 三 层 架 构 中 Model 的 概 念 与 MVC 中 Model 的 概念 是 不 一 样 的 ， “三 层 ”中 典 型 的 Model 层 是 已 实 体 类 构 成 的 ， 而 MVC 里 ， 则

21、 是 由 业 务逻 辑 与 访 问 数 据 组 成 的 。补 充 ：C/S 模式的优点和缺点 C/S 模式的优点 由于客户端实现与服务器的直接相连，没有中间环节，因此响应速度快。 操作界面漂亮、形式多样，可以充分满足客户自身的个性化要求。 C/S 结构的管理信息系统具有较强的事务处理能力，能实现复杂的业务流程。 C/S 模式的缺点 需要专门的客户端安装程序，分布功能弱，针对点多面广且不具备网络条件的用户群体，不能够实现快速部署安装和配置。 兼容性差，对于不同的开发工具，具有较大的局限性。若采用不同工具，需要重新改写程序。 开发成本较高，需要具有一定专业水准的技术人员才能完成。B/S 模式的优点和缺点 B/S 模式的优点 具有分布性特点，可以随时随地进行查询、浏览等业务处理。 业务扩展简单方便，通过增加网页即可增加服务器功能。 维护简单方便，只需要改变网页，即可实现所有用户的同步更新。 开发简单，共享性强。 B/S 模式的缺点 个性化特点明显降低，无法实现具有个性化的功能要求。 操作是以鼠标为最基本的操作方式，无法满足快速操作的要求。 页面动态刷新，响应速度明显降低。 无法实现分页显示，给数据库访问造成较大的压力。 功能弱化，难以实现传统模式下的特殊功能要求。