.NET MAUI 简介

提示

此内容摘自电子书《使用 .NET MAUI 的企业应用程序模式》，可在 .NET 文档上获取，也可作为免费可下载的 PDF 脱机阅读。

下载 PDF

无论平台如何，企业应用的开发人员都面临着几项挑战：

• 可能随时间推移而变化的应用要求。
• 新的商机和挑战。
• 开发过程中不间断的反馈，这些反馈可能会显著影响应用的范围和要求。

考虑到这些，构建可随时间推移轻松修改或扩展的应用非常重要。 针对这种适应性进行设计可能很困难，因为它需要一个体系结构，使应用的各个部分可以独立开发和测试，而不影响应用的其余部分。

许多企业应用非常复杂，需要多名开发人员。 决定如何设计应用，使多个开发人员能够独立有效地处理应用的不同部分，同时确保这些部分在集成到应用中时无缝地结合在一起，这可能是一个巨大的挑战。

设计和生成应用的传统方法会导致形成所谓的整体式应用，此类应用的组件紧密耦合，且它们之间没有明确的分离。 通常，这种整体式方法会导致应用难以维护且效率低下，因为如果不中断应用中的其他组件，很难解决 bug，而且很难添加新功能或替换现有功能。

应对这些挑战的有效方法是将应用划分为离散的松散耦合组件，这些组件可以轻松集成到应用中。 这种方法具有以下优点：

• 允许由不同的个人或团队开发、测试、扩展和维护各个功能。
• 促进了重用，并在应用的横向功能（如身份验证和数据访问）与纵向功能（如特定于应用的业务功能）之间实现明确的关注点分离。 这使应用组件之间的依赖关系和交互更易于管理。
• 允许不同的个人或团队根据自己的专业知识专注于特定任务或部分功能，从而帮助保持角色分离。 具体而言，它在用户界面与应用的业务逻辑之间实现更明确的分离。

但在将应用划分为离散的松散耦合组件时，有许多问题必须解决。 其中包括：

• 决定如何在用户界面控件及其逻辑之间实现明确的关注点分离。 创建 .NET MAUI 企业应用时，为了使应用更易于维护和测试，需要做的最重要的决策之一是将业务逻辑放在代码隐藏文件中，还是在用户界面控件与其逻辑之间实现明确的关注点分离。 有关详细信息，请参阅模型-视图-视图模型。
• 确定是否使用依赖关系注入容器。 依赖关系注入容器通过提供一种工具来构造注入了依赖关系的类实例并根据容器的配置管理它们的生存期，从而减少对象之间的依赖关系耦合。 有关详细信息，请参阅依存关系注入。
• 在不方便通过对象和类型引用进行链接的组件之间，选择进行平台提供的事件处理还是进行基于松散耦合消息的通信。 有关详细信息，请参阅松散耦合组件之间的通信简介。
• 决定如何在页面之间导航，包括如何调用导航以及导航逻辑应位于何处。 有关详细信息，请参阅导航。
• 确定如何验证用户输入的正确性。 该决策必须包括如何验证用户输入，以及如何就验证错误通知用户。 有关详细信息，请参阅验证。
• 决定如何执行身份验证，以及如何使用授权保护资源。 有关详细信息，请参阅身份验证和授权。
• 确定如何从 Web 服务访问远程数据，包括如何可靠地检索数据以及如何缓存数据。 有关详细信息，请参阅访问远程数据。
• 确定如何测试应用。 有关详细信息，请参阅单元测试。

本指南提供有关这些问题的指导，并重点介绍使用 .NET MAUI 构建跨平台企业应用的核心模式和体系结构。 本指南旨在通过解决常见的 .NET MAUI 企业应用开发方案，并通过支持模型-视图-视图模型 (MVVM) 模式为演示、演示逻辑和实体实现关注点分离，从而帮助生成适应性强、可维护且可测试的代码。

示例应用程序

本指南包含一个示例应用程序 eShopOnContainers，它是一个包含以下功能的在线商店：

• 对后端服务进行身份验证和授权。
• 浏览衬衫、咖啡杯和其他市场产品名录。
• 筛选目录。
• 订购目录中的产品。
• 查看用户的订单历史记录。
• 配置设置。

示例应用程序体系结构

下面是示例应用程序体系结构的大致概述。

示例应用程序附带三个客户端应用：

• 使用 ASP.NET Core 开发的 MVC 应用程序。
• 使用 Angular 2 和 Typescript 开发的单页应用程序 (SPA)。 对于 Web 应用程序，这种方法可避免在每次操作时执行到服务器的往返。
• 使用 .NET MAUI 开发的多平台应用，它支持 iOS、Android、macOS（通过 Mac Catalyst）和 Windows 10/11。

有关 Web 应用程序的信息，请参阅使用 ASP.NET Core 和 Microsoft Azure 构建和开发新式 Web 应用程序。

示例应用程序包括以下后端服务：

• 一个标识微服务，它使用 ASP.NET Core 标识和 IdentityServer。
• 一个目录微服务，是一种数据驱动的创建、读取、更新、删除 (CRUD) 服务，该服务通过 EntityFramework Core 使用 SQL Server 数据库。
• 一个订单微服务，是一种使用域驱动设计模式的域驱动服务。
• 一个购物车微服务，是一种使用 Redis 缓存的数据驱动 CRUD 服务。

这些后端服务是使用 ASP.NET Core MVC 以微服务形式实现的，并作为唯一容器部署在单个 Docker 主机中。 这些后端服务统称为 eShopOnContainers 参考应用程序。 客户端应用通过表述性状态转移 (REST) Web 界面与后端服务通信。 有关微服务和 Docker 的详细信息，请参阅容器化微服务。

有关后端服务实现的详细信息，请参阅 .NET 微服务：适用于容器化 .NET 应用程序的体系结构。

多平台应用

本指南重点介绍如何使用 .NET MAUI 构建跨平台企业应用，并使用 eShopOnContainers 多平台应用作为示例。 下图显示了 eShopOnContainers 多平台应用的页面，其中提供前面概述的功能。

多平台应用使用 eShopOnContainers 参考应用程序提供的后端服务。 但对于那些希望避免部署后端服务的用户，可将其配置为使用模拟服务中的数据。

eShopOnContainers 多平台应用运用以下 .NET MAUI 功能：

• XAML
• 控件
• 绑定
• 转换器
• 样式
• 动画
• 命令
• 行为
• 触发器
• 效果
• 自定义控件

有关此功能的详细信息，请参阅 Microsoft 开发人员中心的 .NET MAUI 文档以及使用 .NET MAUI 创建多平台应用。

此外，还为 eShopOnContainers 多平台应用中的某些类提供了单元测试。

多平台应用解决方案

eShopOnContainers 多平台应用解决方案将源代码和其他资源组织到多个项目中。 所有核心移动组件都包含在一个名为 eShopContainers 的单独项目中。 这是 .NET 6 中引入的一项功能，该功能使一个项目能够面向多个输出，从而无需再使用 Xamarin.Forms 和早期 .NET 版本中使用的多平台项目。 还包括一个用于单元测试的额外项目。

虽然此项目将所有组件存储在单一项目中，但可考虑根据需求将该项目分为多个项目。 例如，如果一个服务有多个服务提供程序实现，并且这些实现都有自己的依赖关系，那么将这些服务提供程序实现分别拆分到单独的项目中可能是有意义的。 适合实现项目分离的对象包括共享模型、服务实现、API 客户端组件、数据库或缓存层。 任何你认为企业可在另一项目中重用组件的地方都可实现分离。 然后可通过 NuGet 打包这些项目，以便轻松进分发和版本控制。

所有项目都使用文件夹将源代码和其他资源整理分类。 eShopOnContainers 多平台应用中的类可在任何 .NET MAUI 应用中重复使用，只需少量修改或根本不需要修改。

eShopOnContainers 项目

eShopOnContainers 项目包含以下文件夹：

Folder	说明
动画	包含使动画能在 XAML 中使用的类。
行为	包含向视图类公开的行为。
控件	包含应用所使用的自定义控件。
转换器	包含将自定义逻辑应用于绑定的值转换器。
异常	包含自定义 ServiceAuthenticationException。
扩展	包含 VisualElement 和 IEnumerable<T> 类的扩展方法。
帮助程序	包含应用的帮助程序类。
模型	包含应用的模型类。
属性	包含 .NET 程序集元数据文件 AssemblyInfo.cs。
服务	包含用于实现提供给应用的服务的接口和类。
触发器	包含 BeginAnimation 触发器，该触发器用于在 XAML 中调用动画。
验证	包含验证数据输入所涉及的类。
ViewModels	包含向页面公开的应用程序逻辑。
视图	包含应用的页面。

总结

Microsoft 的跨平台多平台应用开发工具和平台为 B2E、B2B 和 B2C 移动客户端应用提供全面的解决方案，提供跨所有目标平台（iOS、macOS、Android 和 Windows）共享代码的功能并帮助降低总拥有成本。 应用可以共享用户界面和应用逻辑代码，同时保留本机平台的外观。

企业应用的开发人员面临着几项挑战，这些挑战可能会在开发过程中改变应用的体系结构。 因此，请务必构建一个应用，使其可随时间推移进行修改或扩展。 针对这种适应性进行设计可能很困难，但通常涉及将一个应用划分为多个离散的松散耦合组件，这些组件可以轻松集成到应用中。