设计模式-代表性模式_桌面软件设计模式-优快云博客

本文链接：https://blog.youkuaiyun.com/qq_40629687/article/details/135472366

文章详细介绍了几种常见的软件架构模式，包括分层架构模式、客户端-服务器模式、发布-订阅模式、微服务架构、事件驱动架构和领域驱动设计，以及MVC和MVVM模式。每种模式的特点、工作流程和优点都被逐一阐述，展示了它们在IT技术中的应用和价值。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

文章目录

代表性模式

代表性模式

代表性模式-分层架构模式

分层架构模式（Layered Architecture Pattern），也称为分层模式或层次结构模式，是一种常见的软件架构模式，用于将系统按照功能和责任划分为多个层次，使得系统的设计和开发更加模块化、可扩展和易于维护。

分层架构模式层次

分层架构模式将系统划分为多个层次，每个层次具有特定的功能和责任，且各层之间通过明确定义的接口进行通信。典型的分层架构通常包含以下几个层次

表现层（Presentation Layer）：

也称为用户界面层，负责处理用户与系统之间的交互。它包括用户界面、表单验证、用户输入处理等。通常使用各种技术来实现，如Web界面、移动应用界面等。
应用层（Application Layer）：

也称为业务逻辑层，负责实现系统的业务逻辑和处理业务流程。它包括业务规则、数据校验、事务处理等。应用层不依赖于具体的数据存储方式，可独立于其他层进行开发和测试。
领域层（Domain Layer）：

也称为业务对象层，负责封装业务领域的概念和规则。它包括业务实体、值对象、服务等，具体实现业务逻辑并提供对外的接口。领域层是应用层的基础，用于实现业务逻辑的具体细节。
数据访问层（Data Access Layer）：

也称为持久化层，负责与数据存储系统（如数据库、文件系统等）进行交互。它包括数据访问对象（DAO）、数据映射、事务处理等。数据访问层封装了对数据的具体访问和操作，提供给其他层面向数据的接口。

分层架构模式的优点

模块化和可维护性：

每个层次具有清晰的功能和责任，使得系统的设计和开发更加模块化和可维护。
可扩展性：

通过定义明确定义的接口和抽象层，各层之间的依赖关系降低，从而实现系统的可扩展性。
可测试性：

由于各层之间的耦合度较低，每个层次可以独立进行单元测试和集成测试，提高了系统的可测试性。
重用性：

通过将功能划分为层次，可以更好地实现组件和代码的重用。

分层架构模式适用于大型系统和复杂应用，尤其是那些需要灵活性、可扩展性和可维护性的项目。它可以提供清晰的代码结构和逻辑分离，使得团队成员更容易理解和协作开发。同时，分层架构模式也有一定的复杂性，需要合理划分层次和定义接口，以及注意层与层之间的通信和数据传递方式。

代表性模式-客户端-服务器模式

客户端-服务器模式（Client-Server Pattern）是一种常见的分布式计算架构模式，用于将应用程序划分为两个独立的组件：客户端和服务器。客户端提供用户界面和用户交互，而服务器负责处理业务逻辑和数据存储。

在客户端-服务器模式中，客户端是用户直接与之交互的界面，它发送请求到服务器并接收服务器返回的响应。客户端通常是在用户设备上运行的应用程序，如桌面应用程序、移动应用程序或Web浏览器。

服务器是运行在服务器端的应用程序，它接收客户端的请求并处理业务逻辑。服务器通常负责数据存储和处理、计算、身份验证和授权等任务。服务器可以是单个物理服务器或者是由多台服务器组成的服务器集群。

客户端和服务器之间通过网络进行通信，客户端发送请求消息到服务器，服务器处理请求并返回响应消息给客户端。通常使用不同的网络协议和通信机制来实现客户端和服务器之间的通信，如HTTP、TCP/IP、RESTful API等。

客户端-服务器模式的优点

分工明确：

客户端负责用户界面和用户交互，服务器负责业务逻辑和数据存储，使得系统的职责分工明确。
可扩展性：

由于客户端和服务器是独立的组件，可以独立扩展和部署，从而实现系统的可扩展性。
跨平台和跨设备：

客户端可以运行在不同的设备和平台上，如桌面、移动设备和Web浏览器，服务器可以部署在任何支持的服务器端环境上。
安全性：

通过将业务逻辑和数据存储放在服务器端，可以实现更强的安全性控制，对敏感数据和操作进行保护。

客户端-服务器模式适用于需要分离用户界面和业务逻辑的应用场景。它常用于Web应用程序、移动应用程序、数据库系统、分布式系统等。这种模式提供了一种有效的方式来处理大规模应用程序的复杂性，并实现可扩展性和可维护性。

代表性模式-发布-订阅模式

发布-订阅模式（Publish-Subscribe Pattern），也称为观察者模式或消息队列模式，是一种软件设计模式，用于解耦发布者（发布消息的一方）和订阅者（接收消息的一方），使得它们可以独立地演化。

发布-订阅模式三个核心角色

发布者（Publisher）：

也称为主题（Subject）或消息发布者，负责产生消息并将其发送给订阅者。发布者不需要知道订阅者的存在，它只需将消息发布到特定的主题或频道。
订阅者（Subscriber）：

也称为观察者（Observer）或消息接收者，注册并订阅感兴趣的主题或频道，接收发布者发送的消息。订阅者可以订阅多个主题，也可以选择性地接收消息。
中介者（Mediator）：

也称为消息队列、消息代理或事件总线，负责管理发布者和订阅者之间的通信和消息传递。它接收发布者发送的消息，并将其传递给所有订阅该消息的订阅者。

发布-订阅模式的工作流程

发布者产生消息，并将其发送给中介者。
中介者接收到消息后，根据订阅者的注册信息，将消息分发给订阅该消息的订阅者。
订阅者接收到消息后，执行相应的操作或逻辑。

发布-订阅模式的优点

解耦性：

发布者和订阅者之间相互独立，彼此不知道对方的存在，从而实现了解耦。
可扩展性：

可以轻松添加新的发布者和订阅者，而不需要修改现有的代码。
灵活性：

订阅者可以选择性地接收感兴趣的消息，而不会受到其他消息的干扰。
实时性：

发布者发送消息后，订阅者可以立即接收到消息，实现实时的消息传递。
可靠性：

中介者负责管理消息传递，确保消息的可靠投递和传递。

发布-订阅模式适用于需要解耦发布者和订阅者之间的系统，尤其是在异步通信和分布式系统中。它常用于事件驱动系统、消息队列、消息中间件等场景，如消息传递系统、实时通信应用、分布式日志系统等。

代表性模式-微服务架构模式

微服务架构模式（Microservices Architecture Pattern）是一种软件设计和开发模式，用于构建大型应用程序，将应用程序划分为一组小型、自治的服务，每个服务都可以独立开发、部署和扩展。

在微服务架构中，应用程序被拆分为多个小型的服务，每个服务都专注于实现一个特定的业务功能。每个服务都是独立部署的，并且可以使用不同的编程语言、技术堆栈和数据存储。这些服务通过轻量级的通信机制（通常是通过HTTP或消息队列）进行交互，形成一个松散耦合的系统。

微服务架构的核心原则

单一责任原则：

每个微服务负责实现一个特定的业务功能，具有独立的责任和职责。
服务自治：

每个微服务都是自治的，具有自己的数据存储和业务逻辑，可以独立开发、部署和扩展。
松耦合通信：

微服务之间通过轻量级的通信机制进行交互，如使用HTTP API、消息队列或事件总线。
垂直拆分：

应用程序按照业务边界进行拆分，将大型单体应用拆分为多个小型的、可独立部署的服务。
弹性和可伸缩性：

由于每个微服务都是独立部署的，可以根据需求独立扩展和缩减服务的实例数量。

微服务架构的优点

独立开发和部署：

每个微服务都可以由不同的团队独立开发和部署，加快开发速度和部署频率。
可扩展性：

由于每个微服务可以独立扩展，可以根据负载和需求进行横向扩展，提高系统的性能和可扩展性。
独立技术选择：

每个微服务可以选择适合其需求的技术堆栈，使得团队可以使用最合适的工具和技术来解决问题。
容错性：

由于微服务之间是松耦合的，一个服务的故障不会影响整个系统的运行，提高了系统的容错性和可靠性。
可组合性和重用性：

微服务的独立性和自治性使得它们可以在不同的应用中进行组合和重用，提高了代码的可组合性和重用性。

然而，微服务架构也带来了一些挑战，如服务间通信的复杂性、分布式事务的处理、服务发现和治理等。因此，在采用微服务架构时，需要仔细考虑这些挑战，并采取相应的解决方案来应对。

微服务架构适用于大型和复杂的应用程序，尤其是在需要灵活性、可扩展性和独立部署的场景下。它常用于云原生应用开发、分布式系统、大规模Web应用、企业级应用等。

代表性模式-事件驱动架构模式

事件驱动架构（Event-Driven Architecture，EDA）是一种软件架构模式，其中系统的各个组件通过事件进行通信和协作。在事件驱动架构中，组件之间的交互是基于事件的产生、发布、订阅和处理。

在事件驱动架构中，系统中的各个组件可以充当事件的生产者或消费者。事件可以是系统内部的状态变化、用户操作、外部系统的通知等。当一个事件发生时，它会被发布到一个或多个感兴趣的订阅者，订阅者会接收到该事件并做出相应的处理。

事件驱动架构的核心概念

事件（Event）：

系统中发生的有意义的事情，可以是状态变化、用户交互、消息通知等。
发布者（Publisher）：

事件的生产者，负责将事件发布到事件总线或消息队列中。
订阅者（Subscriber）：

事件的消费者，通过订阅感兴趣的事件类型，接收并处理事件。
事件总线（Event Bus）：

用于事件的发布和订阅，充当事件的中介者，负责将事件传递给订阅者。
事件处理器（Event Handler）：

订阅者中的组件，负责处理特定类型的事件，并执行相应的逻辑。

事件驱动架构的优点

松耦合：

事件驱动架构解耦了系统中的各个组件，每个组件只关注自己感兴趣的事件，而不需要直接依赖其他组件。
可扩展性：

由于组件之间是松耦合的，可以轻松添加或移除组件，实现系统的可扩展性。
异步性：

事件驱动架构支持异步处理事件，提高系统的响应性和吞吐量。
可靠性：

通过使用事件总线或消息队列，可以确保事件的可靠传递和处理，即使其中的某个组件发生故障。

事件驱动架构适用于需要解耦组件、实现异步通信、处理大量事件的场景。它常用于事件驱动系统、实时流处理、消息驱动的架构、响应式系统等。事件驱动架构可以帮助构建灵活、可扩展和可维护的系统，提高系统的可伸缩性和性能。

代表性模式-领域驱动设计模式

领域驱动设计（Domain-Driven Design，DDD）是一种软件开发方法和设计模式，旨在帮助开发人员解决复杂领域的设计和实现问题。DDD 关注的是领域模型（Domain Model）的设计和建模，将业务领域的知识和规则集中到软件系统中。

在领域驱动设计中，领域是指业务领域，即问题域或系统要解决的特定领域。领域模型是对领域的概念、规则和行为的抽象表示，它是基于业务需求和业务知识构建的。

领域驱动设计模式关键概念

聚合（Aggregate）：

聚合是领域模型的核心概念，代表一组相关的对象的集合。聚合内有一个根实体（Aggregate Root），通过根实体来管理和维护聚合内的对象。
实体（Entity）：

实体是领域模型中具有唯一标识的对象，它具有生命周期和状态，并可以在系统中被识别、追踪和操作。
值对象（Value Object）：

值对象是没有唯一标识的对象，它是通过其属性来定义和区分的。值对象是不可变的，用于描述某个概念或属性。
领域服务（Domain Service）：

领域服务是领域模型中的一种行为，它不属于任何具体的实体或值对象，负责处理一些领域操作和业务逻辑。
聚合根（Aggregate Root）：

聚合根是聚合中的一个特殊实体，它是聚合的入口点，负责维护整个聚合的完整性和一致性。
领域事件（Domain Event）：

领域事件表示在领域中发生的某个重要事件，可以被订阅和处理。

领域驱动设计模式的目标是将业务领域的知识融入到软件设计中，通过使用领域模型来解决复杂的业务问题。它强调领域专家与开发团队之间的合作，通过共同的语言和模型来达成共识。

领域驱动设计模式能够提高软件系统的可维护性、可扩展性和可理解性，特别适用于复杂领域和大型系统的开发。它能够帮助开发人员更好地理解和应对业务需求，将复杂的业务逻辑和规则表达清晰，提高系统的质量和开发效率。

代表性模式-MVC模式

MVC（Model-View-Controller）是一种软件设计模式，用于将应用程序的逻辑、数据和用户界面分离。它提供了一种结构化的方式来组织和管理应用程序的代码，使得代码更具可维护性、可扩展性和可重用性。

MVC模式由以下三个主要组件

模型（Model）：

模型代表应用程序的数据和业务逻辑。它负责处理数据的存储、检索和处理，并提供一组接口供控制器和视图进行交互。
视图（View）：

视图负责展示模型的数据给用户，并处理用户界面的交互。它是模型的可视化呈现，负责向用户展示数据和接收用户输入。
控制器（Controller）：

控制器是模型和视图之间的中间人，负责处理用户输入、更新模型的数据，并将更新的数据传递给视图进行展示。它处理用户的请求、调用适当的模型方法，并根据模型的状态更新视图。

MVC模式的工作流程

用户与视图进行交互，例如点击按钮或输入数据。
视图将用户的交互事件传递给控制器。
控制器接收到用户的交互事件后，根据事件类型和应用程序的逻辑进行处理。
控制器可能会更新模型的状态，执行相关的业务逻辑，并将更新的数据传递给视图。
视图接收到控制器传递的数据后，根据数据更新自身的显示内容，以便将更新的数据展示给用户。

MVC模式的优点

分离关注点：

MVC模式将应用程序的逻辑、数据和用户界面分离，使得各个组件之间的关注点清晰明确，易于维护和修改。
可重用性：

通过将逻辑和数据与界面分离，可以使模型和控制器在不同的视图中重复使用，提高代码的可重用性。
可扩展性：

由于模型、视图和控制器之间的松耦合关系，可以方便地扩展和修改每个组件，而不会对其他组件产生影响。
可测试性：

MVC模式使得各个组件的功能单元化，易于进行单元测试和集成测试，提高代码的可测试性。

MVC模式广泛应用于Web开发和桌面应用程序开发中。在Web开发中，模型表示数据模型和业务逻辑，视图表示前端界面，控制器表示后端逻辑和路由。在桌面应用程序开发中，MVC模式可以用于分离应用程序的数据、界面和业务逻辑，提高应用程序的可维护性和可扩展性。

代表性模式-MVVM模式

MVVM（Model-View-ViewModel）是一种软件架构模式，旨在实现数据绑定和分离用户界面逻辑和业务逻辑的目标。MVVM模式扩展了MVC模式，引入了ViewModel作为连接模型和视图的中间层。

MVVM模式由三个主要组件

模型（Model）：

模型代表应用程序的数据和业务逻辑，与MVC模式中的模型类似。它负责数据的存储、检索和处理。
视图（View）：

视图负责展示模型的数据给用户，并处理用户界面的交互。视图可以是用户界面的任何部分，如页面、窗口、控件等。
视图模型（ViewModel）：

视图模型是模型和视图之间的中间层，它负责将模型的数据进行转换和封装，以便视图能够直接使用。视图模型暴露给视图的是可供绑定的属性和命令，它不仅包含数据，还包含了视图的交互逻辑和状态。

MVVM模式的工作流程

用户与视图进行交互，例如点击按钮或输入数据。
视图将用户的交互事件传递给视图模型。
视图模型接收到用户的交互事件后，根据事件类型和应用程序的逻辑进行处理。
视图模型可能会更新模型的状态，执行相关的业务逻辑，并将更新的数据进行封装和转换。
视图模型将封装和转换后的数据暴露给视图，以便视图能够直接使用。
视图根据视图模型提供的数据进行更新，将更新的数据展示给用户。

MVVM模式的优点

分离关注点：

MVVM模式将应用程序的数据、视图和交互逻辑分离，使得各个组件之间的关注点清晰明确，易于维护和修改。
可重用性：

通过将视图模型从视图中解耦，可以使得视图模型在不同的视图中重复使用，提高代码的可重用性。
可测试性：

由于视图模型仅包含视图的交互逻辑和状态，易于进行单元测试和集成测试，提高代码的可测试性。
数据绑定：

MVVM模式支持双向数据绑定，使得视图和视图模型之间的数据同步更加简便。

MVVM模式的优点

分离关注点：

MVVM模式将应用程序的数据、视图和交互逻辑分离，使得各个组件之间的关注点清晰明确，易于维护和修改。
可重用性：

通过将视图模型从视图中解耦，可以使得视图模型在不同的视图中重复使用，提高代码的可重用性。
可测试性：

由于视图模型仅包含视图的交互逻辑和状态，易于进行单元测试和集成测试，提高代码的可测试性。
数据绑定：

MVVM模式支持双向数据绑定，使得视图和视图模型之间的数据同步更加简便。

MVVM模式在基于桌面应用程序、Web应用程序和移动应用程序开发中广泛应用。在桌面应用程序中，MVVM模式通常与WPF（Windows Presentation Foundation）和Silverlight等技术结合使用。在Web应用程序中，MVVM模式通常与前端框架（如Angular、React和Vue.js）结合使用。在移动应用程序中，MVVM模式通常与框架（如Flutter和React Native）结合使用。