开原网站网站建设,如何制作课程网站模板下载地址,公司装修报价,石家庄的网站建设公司选择风格(Choosing a style)
我们将依照Google在《应用架构指南》中推荐的最佳实践和架构指南来构建OrderNow的架构。
这些定义包括通过各层定义组件的一些Clean Architecture原则。
层次的定义(Definition of the layers)
在应用程序中#xff0c;我们将定义以下主要层次…选择风格(Choosing a style)
我们将依照Google在《应用架构指南》中推荐的最佳实践和架构指南来构建OrderNow的架构。
这些定义包括通过各层定义组件的一些Clean Architecture原则。
层次的定义(Definition of the layers)
在应用程序中我们将定义以下主要层次
• 用户界面UI层
• 领域层
• 数据层
UI层(UI Layer)
这一层组合了UI元素Views视图composable functions可组合函数ViewModels和表示层的实用程序例如格式应用器和动画。 设计这一层的注意事项包括
• 对于状态处理遵循设计原则中描述的原则。
• 对于每个屏幕将实现相应的ViewModel。
•viewmodels也将作为状态持有者也就是状态管理器。 •导航逻辑将委托给视图并将依赖于APP的状态。 •副作用应该报告给ViewModel。 •当配置发生变化时Views模型应该保持它们的状态。 •鼓励使用stateless Views(无状态视图)。 领域层(Domain Layer)
尽管这一层可以是可选的但我建议包含它以保持与 Clean Architecture 规定的责任划分一致的设计。
这一层组合了被称为 UseCases 的组件这些组件将管理业务逻辑和所有可由 ViewModels 重用的逻辑。
这一层还作为 UI 层(UI Layer)和数据层(Data Layer)之间的桥梁。
Models 类型的组件也属于这一层。
这些组件对表示层或领域层使用的实体或数据结构进行建模。例如在 OrderNow 中“产品”和“类别”都表示模型或实体。
UseCases (用例)是一种设计模式用于定义特定的业务逻辑或应用程序功能。它们用于封装特定的应用程序操作通常涉及从数据层获取数据、处理数据以及将结果传递给UI层。在使用清洁架构时UseCases 通常在领域层中定义并由UI层调用。 关于这一层的设计考虑包括
• 所有在视图中重复的展示逻辑都可以放在UseCases (用例)中。
• 属于此层的组件可以是无状态的它们是不需要临时持久化的组件。
• UseCases (用例)执行的操作必须是主线程安全的。
• UseCases 可以相互通信以协调用例操作。 • 每个 UseCases 负责一个且只有一个操作。
• 每个 UseCases 可能会使用一个或多个仓库Repositories。
数据层Data Layer
这一层组织了名为仓库Repositories的组件它们协调和封装了与本地和远程数据源的集成逻辑。如其名称所示它们遵循仓库模式。 这一层的其他组件包括数据源Datasources、映射器Mappers和数据传输对象DTOs。
• 数据源Datasource包含到外部或本地持久化源的逻辑集成。
• 数据传输对象DTO它是模型持久化实体的结构。包含持久性机制使用的定义。为了使其他层UI和领域不继承这些定义这些类型的实体通过映射器转换为应用程序域的模型。
映射器它们将 DTO 转换为领域层的模型实体。对于此层的设计建议考虑以下事项
• 此层可用作事实来源。
• 存储库执行的操作必须是主安全的。
• 为每个主要实体类型定义一个存储库例如产品存储库、类别存储库。 通用架构General architecture
不同集成层的通用图类似如下:
Architecture Layers 架构层 关于其他层
补充架构主要层次的其他辅助层将包括
• Main主层包含应用程序的基础构件例如 MainActivity、Application 和 ApplicationState 等等。
• Common(通用层)包含跨应用程序的构件例如导航定义、用于其他层的实用工具和依赖管理器等等。
关于 PortsClean 架构的使用
建议在不同层的边界之间包括端口这种技术允许反转控制解耦在每层边界之间通信的组件。这种方法将为设计增加更好的可维护性和适应性。我们的示例应用程序 OrderNow 将在Domain Layer 和Data layer之间添加端口。 组织目录(Organizing directories)
在我们的OrderNow示例中为了简单起见层次将通过单个模块中的目录以单体方式组织。 我将把是否在后续的项目中决定分离各层并为每个层献出一个模块的决定留给读者自行判断。
通过两个定义来进行目录组织
• 在UI层将使用按功能组织。
• 在Domain Layer(领域层)和Data Layer(数据层)将使用按组件组织。 元素的命名和规范
对于组件命名我们将使用以下规则
使用后缀 只有在以下情况下才会在组件名中使用后缀
• 包含包的名称没有推断出其类型。
• 需要强制组件代表的结构类型例如ProductRepository。
• 为了避免组件类型之间的混淆例如一个模型可能被命名为Category其存储库名为 CategoryRepository。
后缀命名: 命名包
应用程序包的名称必须为小写不能有分隔符也不能有驼字。 命名组件
对于组件类型UseCases的名称表示用例中的操作(do, get, update, save, send, delete, add,执行、获取、更新、保存、发送、删除、添加)的操作被用作前缀。 命名可组合函数 对于UI组件也就是可组合函数的定义我们将使用以下的命名规则这些规则参考了Google在架构指南中的文档²⁷
Screen用于表示整个屏幕的可组合函数的后缀。 屏幕
UI用于composables这些composables将视图的状态UI State与组件的图形表示UI Elements结合在一起。 用户界面
Elements用于定义UI库组件Buttons, Layouts, Checkbox, TextFields ,如按钮、布局、复选框、文本字段等的composables的后缀这些组件构成了视图。 元素
Preview用于预览视图元素的composables的前缀。Screen和UI composables也可以被组合预览但由于对状态和其他变量的依赖性它变得更加复杂。
注意
在构建应用程序时虽然定义所有的组件类型很重要但也可能存在例外情况不需要定义所有的组件类型可以省略一些。具体取决于应用程序中屏幕的复杂程度需要决定哪些组件类型适用哪些不适用。 本章中我想描述在开始实现之前要遵循的架构定义。还澄清了用于组织应用程序项目的规则。我必须澄清本章中给出的定义是建议性的。读者可以自定义或假定适合自己的约定和规则或者在实现中感到舒适的约定和规则。在下一章中我们将开始实现OrderNow首先要构建的是它的框架即它的主要结构。
