使用三层架构的任务管理系统

• 下载源代码 - 953.89 KB

引言

随着时间的推移，现实世界中的应用程序变得越来越健壮和复杂，使得开发人员很难扩展应用程序。为了解决这个问题，开发人员会使用一种技术。在这种技术中，他们根据标准将整个应用程序分成几个部分。在应用程序设计方面，他们将这些部分称为“层”，并将这种技术称为“层架构”。在本文中，我将重点介绍三层架构。

三层架构的描述

在这种设计技术中，整个应用程序被分成三个部分，因此称为三层架构。它们是：

1. 表示层（用户界面）
2. 业务逻辑层 (BLL)
3. 数据层

表示层

表示层是应用程序设计架构的前端，它为程序员或最终用户提供用户界面。程序员使用此层进行设计，以及来回获取或设置数据。

业务逻辑层

业务逻辑层是应用程序设计架构的中间层，它连接了前端和后端。所有业务逻辑都在此层实现。此层是一个类，我们使用它来编写函数，这些函数充当介质，将数据从应用程序或表示层数据层传输过来。在三层架构中，我们绝不允许数据访问层与表示层交互。

数据层

这是应用程序设计架构的后端，它负责数据的访问、检索、更新和存储。数据层有两个子层：数据访问层和数据库。数据访问层也是一个类，我们使用它来往返于数据库获取或设置数据。此层仅与数据库交互。我们编写数据库查询或使用存储过程来从数据库访问数据或对数据库执行任何操作。在本文中，我将数据访问层分为两部分：一是包含实际实体和用于访问数据库数据的网关的数据访问对象（DAO）。

一个实时场景

在过去，我曾实现了一个基于三层架构的项目。我将从该项目的角度解释所有术语。该项目名为“任务管理系统”，它是在软件开发团队的某个场景下构建的。在该项目场景中，开发团队的所有成员根据其角色分为四类：超级管理员、管理员、用户和员工。

超级管理员是此应用程序中最强大的角色，他可以创建和删除管理员、用户和员工。管理员有权创建项目、将用户包含在项目中、创建任务并将任务分配给包含在项目中的用户。他还可以关闭项目和任务，并将任何任务从用户转发给用户。管理员和用户都可以查看他们的任务列表、评论任务、在评论中附加文件，以及将任务转发给项目中的用户。

分析

首先，根据项目场景，我找出项目中的对象——即用户、项目、任务和评论。为了降低设计复杂性，我还添加了两个扩展对象：项目详细信息和任务详细信息。这两个扩展对象维护任务、项目和用户之间的关系。这六个对象用作数据访问层的数据访问对象。此处使用网关类来访问数据。

这里我使用业务逻辑层来通信数据访问层，实现所有业务逻辑，并进行一些验证。

如前所述，该项目是基于三层架构设计的，并且我将其实现为一个基于 Web 的应用程序。这里的表示层是 Web 窗体，它与最终用户交互并显示数据。

在图 1 的图表中，您可以看到一个过程。该过程经过以下 6 个步骤：

1. 表示层向 BLL 请求某个对象，例如用户的任务列表。

   

2. BLL 可以选择性地执行一些验证（例如，所有任务是否都在运行？），然后将请求转发给 DAL。

   public DataTable SelectTaskInformationOfUser(string userId)
   {
       TaskGateWay taskGateWayObj = new TaskGateWay();
       return taskGateWayObj.SelectTaskOfOwnerUser(userId);
   }

3. DAL 连接到数据库，并从中请求特定记录。

   public DataTable SelectTaskOfOwnerUser(string userId)
   {
       DEC = new DataExecuteClass();
       string selectString = "exec TaskOfUser '"+userId+"'";
       DataTable dt = DEC.getDataSet(selectString).Tables[0];
       return dt;
   }

4. 找到记录后，它将从数据库返回到 DAL。
5. DAL 将记录返回给 BLL。
6. 最后，BLL 将数据返回给表示层，例如可以在网页上显示。

优点

将应用程序拆分成不同层的设计有几个优点。最重要的是，这种架构形式有助于强制执行系统组件之间高内聚、低耦合的原则。基于这些原则构建的系统将更健壮、更容易调整、更易于维护和理解，并且允许不同的软件组件并行开发。关键在于，系统应该被拆分成尽可能内聚和自治的更小的部分。每个部分都有明确的职责，并与其他系统部分交互以完成其任务和职责。这还确保系统可以跨不同平台和通信协议进行协作，并使重用现有解决方案来解决经常遇到的问题变得更容易。总而言之，这些优点是可取的，因为它们朝着低耦合和高内聚的方向发展。然而，困难之处在于实际实现它，以及知道何时以及如何实现它。哪些对象应该负责不同的任务以及它们如何交互。这就是设计模式发挥重要作用的地方。

历史

• 2010年4月9日：初始发布