架构
使用Avalonia构建跨平台应用程序的一个关键方面是创建一种架构,可以在不同平台之间实现最大程度的代码共享。通过遵循面向对象编程的基本原则,您可以建立一 个结构良好的应用程序:
- 封装 - 这涉及确保类和架构层只公开执行其必要功能的最小API,同时隐藏内部实现细节。在实际应用中,这意味着对象作为“黑盒”运行,使用它们的代码不需要理解其内部工作原理。在架构上,这意味着实现促进简化API的模式,如外观模式,代表更高抽象层中的代码进行更复杂的交互。因此,UI代码应仅关注显示屏幕和接受用户输入,而不直接与数据库或其他低级操作进行交互。
- 责任分离 - 每个组件,无论是在架构层还是类级别,都应具有明确和定义的目的。每个组件应执行其指定的任务,并通过API将该功能暴露给其他需要使用它的类。
- 多态性 - 编程到支持多个实现的接口(或抽象类)允许核心代码在不同平台之间编写和共享,同时与Avalonia提供的特定于平台的功能进行交互。
这些原则的结果是一个模拟现实世界或抽象实体的应用程序,具有明确的逻辑层次结构。
将代码分离为层使应用程序更易于理解、测试和维护。建议将每个层中的代码物理上分开(可以在不同的目录中或者对于较大的应用程序甚至是不同的项目中)以及逻辑上分开(使用命名空间)。使用Avalonia,您不仅可以共享业务逻辑,还可以跨平台共享UI代码,从而减少了对多个UI项目的需求,并进一步增强了代码重用。
典型的应用程序层次结构
在本文档和相关案例研究中,我们引用以下五个应用程序层:
- 数据层 - 这是非 易失性数据持久化发生的地方,通常通过像SQLite或LiteDB这样的数据库,但也可以使用XML文件或其他适当的机制来实现。
- 数据访问层 - 这一层是围绕数据层的包装器,提供对数据的创建、读取、更新、删除(CRUD)操作,而不向调用者透露实现细节。例如,数据访问层可能包含与数据交互的SQL查询,但引用它的代码不需要知道这一点。
- 业务层 - 有时也称为业务逻辑层或BLL,该层包含业务实体定义(模型)和业务逻辑。它是业务外观模式的一个主要候选者。
- 服务访问层 - 这一层用于访问云中的服务,从复杂的Web服务(REST,JSON)到从远程服务器检索数据和图像的简单操作。它封装了网络行为,并提供了一个简化的API,供应用程序和UI层使用。
- 应用程序层 - 这一层包含通常是特定于平台的代码或特定于应用程序的代码(通常不可重用)。在Avalonia框架中,这一层决定了是否利用特定于平台的功能。在Avalonia中,由于UI代码可以在各个平台之间共享,因此这一层与UI层之间的区别变得更加清晰。
- 用户界面(UI)层 - 这个面向用户的层包含视图和管理它们的视图模型。与传统架构不同,Avalonia使得这一层可以在每个支持的平台上共享,而不是特定于平台。
一个应用程序可能不包含所有的层 - 例如,如果一个应用程序不访问网络资源,那么服务访问层就不会存在。一个更简单的应用程序可能会合并数据层和数据访问层,因为操作非常基本。使用Avalonia,您可以根据自己的特定需求灵活地塑造应用程序架构,享受在不同平台上高度可重用的代码。