app开发 持久性模型是理想之选，原因是分离关注点
发表时间：2023-10-09 14:02:20
文章来源：炫佑科技
浏览次数：122
菏泽炫佑科技
app开发 持久性模型是理想之选app开发 持久性模型是理想之选，原因是分离关注点，原因是分离关注点
请注意，您不拥有 和 的实现； 它们只是代表操作系统和应用程序之间关系的粘合类。 操作系统可能会根据用户交互或由于内存不足等系统条件随时销毁它们。 为了提供令人满意的用户体验和更易于管理的应用程序维护体验，*好尽量减少对它们的依赖。
数据模型驱动接口
另一个重要原则是您应该通过数据模型（*好是持久性模型）来驱动接口。 数据模型代表应用程序的数据。 它们独立于应用程序中的 UI 元素和其他组件。 这意味着它们与界面和应用程序组件的生命周期无关，但当操作系统决定从内存中删除应用程序的进程时，它们仍然会被销毁。
持久性模型是理想的，原因如下：
如果您的应用程序架构基于数据模型类，您的应用程序将更容易测试并且更加稳定可靠。
单一数据源
当您在应用程序中定义新的数据类型时，您应该为其分配单一数据源 (SSOT)。 SSOT 是数据的所有者，只有 SSOT 才能修改或转换数据。 为了实现这一点，SSOT 将数据公开为不可变类型； 为了修改数据，SSOT 公开其他类型可以调用的函数或接收事件。
该模型有几个优点：
在离线优先的应用程序中，应用程序的单一数据源通常是数据库。 在其他一些情况下，单一数据源甚至可以是一个接口。
单向数据流
在我们的指南中，它通常与单向数据流 (UDF) 模式一起使用。 在 UDF 中，状态仅沿一个方向流动。 以相反方向修改数据流的事件。
在分区层次结构中，状态或数据通常从较高分区类型流向较低分区类型。 事件通常在分区层次结构中较低的分区类型上触发，直到它们到达 SSOT 的相应数据类型。 例如，应用程序数据通常从数据源流向接口。 用户事件（例如按下按钮）从界面流向 SSOT，其中应用程序数据被修改并公开为不可变类型。
这种模式可以更好地保证数据一致性，不易出错，更容易调试，并且具有SSOT模式的所有优点。
推荐的应用架构
本部分演示如何按照推荐的*佳实践构建应用程序。
注意：本页提供的建议和*佳实践可应用于各种应用程序。 遵循这些建议和*佳实践可以提高应用程序的可扩展性、质量和稳健性，并使应用程序更易于测试。 但是，您应该将这些提示视为指南，并根据需要进行调整以满足您的要求。
基于上一节中提到的通用架构原则，每个应用程序都应该至少有两层：
您可以添加一个称为“域层”的附加架构层来简化和重用接口层和数据层之间的交互。
图 1. 典型应用架构示意图。 注意：本指南中图表中的箭头表示类之间的依赖关系。 例如，领域层依赖于数据层类。 现代应用程序架构
这种现代应用程序架构鼓励以下方法和其他方法：
要了解更多信息，请参阅以下部分、目录中的其他架构页面以及建议页面app开发，其中包含*重要的*佳实践的摘要。
接口层
界面层（或表示层）用于在屏幕上显示应用程序数据。 每当数据发生变化时，无论是由于用户交互（例如按下按钮）还是外部输入（例如网络响应），界面都应该更新以反映这些变化。
接口层由以下两部分组成：
图 2. 接口层在应用程序架构中的作用。
要了解有关此层的更多信息，请参阅接口层页面。
数据层
应用程序的数据层包含业务逻辑。 业务逻辑决定应用程序的价值，并包含确定应用程序如何创建、存储和更改数据的规则。
数据层由多个仓库组成，每个仓库可以包含零到多个数据源。 您应该为应用程序中处理的每种不同类型的数据创建一个存储库类。 例如，您可以为与电影相关的数据创建一个类，或者为与付款相关的数据创建一个类。
图 3. 数据层在应用程序架构中的作用。
存储库类负责以下任务：
每个数据源类应该只负责处理一个数据源，该数据源可以是文件、网络源或本地数据库。 数据源类是应用程序和数据操作系统之间的桥梁。
要了解有关此层的更多信息，请参阅数据层页面。
领域层
领域层是接口层和数据层之间的可选层。
领域层负责封装复杂的业务逻辑，或者被多个应用程序重用的简单业务逻辑。 该层是可选的，因为并非所有应用程序都有此要求。 仅在需要时使用此层，例如处理复杂逻辑或支持可重用性。
图 4. 领域层在应用程序架构中的作用。
该层中的类通常称为“用例”或“交互方”。 每个用例应该只负责一个功能。 例如，如果多个应用程序依赖时区在屏幕上显示适当的消息，则您的应用程序可能具有类。
要了解有关此层的更多信息，请参阅域层页面。
管理组件之间的依赖关系
应用程序中的类依赖于其他类才能正常运行。 您可以使用以下任何设计模式来收集特定类的依赖项：
这些模式允许您扩展代码，因为它们提供了清晰的依赖关系管理模型（无需重复代码或增加复杂性）。 此外，这些模式允许您在测试和生产实施之间快速切换。
我们建议在您的应用程序中采用依赖注入模式并使用 Hilt 库。 Hilt 通过遍历依赖树自动构造对象，为依赖提供编译时保证，并为框架类创建依赖容器。
常见的*佳实践
编程是一个创造性的领域，构建应用程序也不例外。 无论是在多个文件之间传递数据、检索远程数据并将其保存在本地以供离线模式使用，还是复杂应用程序遇到的任何其他常见情况，都有多种方法可以解决问题。
虽然以下建议不是强制性的，但在大多数情况下，遵循这些建议将使您的代码库更加健壮、更易于测试且更易于维护：
不要将数据存储在应用程序组件中。
避免将应用程序的入口点（例如 、 和广播接收器）指定为数据源。 相反，您应该仅将其与其他组件协调以检索与该入口点相关的数据子集。 每个应用程序组件仅短暂存在，具体取决于用户与其设备的交互以及系统当前的整体运行状况。
减少对课程的依赖。
您的应用程序组件应该是唯一依赖于框架 SDK API 的类（例如，Toast）。 将这些类与应用程序中的其他类分开有助于提高可测试性并减少应用程序中的耦合。
在应用程序的各个模块之间设置明确定义的职责范围。
例如，不要将从网络加载数据的代码分布在代码库中的多个类或包中。 同样，不要将不相关的职责（例如数据缓存和数据绑定）定义到同一个类中。 下面可以帮助您解决这个问题。
在每个模块中暴露尽可能少的代码。
例如，不要尝试创建提供模块内部实现细节的快捷方式。 从短期来看，您可能会节省一些时间，但随着代码库的不断增长，您可能会一次又一次地遇到技术问题。
专注于应用程序的独特核心，使其从其他应用程序中脱颖而出。
不要一遍又一遍地编写相同的样板代码，这是浪费时间。 相反，您应该将时间和精力集中在使您的应用程序独一无二的方面，并让库和其他建议的库处理重复的样板文件。
考虑如何使应用程序的每个部分都可独立测试。
例如，如果您使用定义良好的 API 从网络获取数据，则测试将该数据保留在本地数据库中的模块会更容易。 如果将这两个模块的逻辑混合在一起，或者将网络代码分布在整个代码库中，则有效测试将变得更加困难（如果不是不可能的话）。
类型负责其并发策略。
如果某个类型正在执行长时间运行的阻塞工作，则有责任将该计算移至正确的线程。 该特定类型知道它正在执行什么类型的计算以及应该在哪个线程中执行。 类型应该是主线程安全的，这意味着您可以安全地从主线程调用它们而不会阻塞。
保留尽可能多的相关和*新数据。
这样，即使用户的设备处于离线模式，他们也可以使用您应用的功能。 请记住，并非所有用户都能获得稳定、高速的连接 - 即使有时可以工作，在较拥挤的区域信号也可能不好。
架构优势
在应用程序中实现良好的架构可以为项目和工程团队带来许多好处：
对架构的投资也会对您的用户产生直接的积极影响。 由于工程团队效率的提高，用户受益于更稳定的应用程序并享受更多功能。 然而，架构也需要前期投入时间。 我建议阅读这些案例研究，了解其他公司如何在其应用程序中成功使用良好的架构。 这将帮助您向公司解释前期投入时间的必要性。
例子
以下示例展示了良好的应用程序架构。 查看这些示例，了解如何将本指南付诸实践：
为你推荐
