CleanArchitecture 3.1.158

CleanArchitecture 3.1.158

Iturbide 维护。



  • iturbide

Clean Architecture

iOS Swift Build Status

  1. 说明
  2. 原理
  3. 动机
  4. 适用性
  5. 结构
  6. 实现
  7. 演示

说明

Clean Architecture 是一个框架,可以帮助您在应用程序中创建关注点的分离;它深受 BobUncle 的 Clean Architecture 启发。您可以在 The Clean Code Blog 上了解更多信息。

框架

设计重用优于代码重用

  • 预先定义设计参数,以便实施者可以专注于应用程序的具体细节。
  • 定义总体结构,将其划分为类和对象,并定义其关键责任,类和对象之间的协作方式以及控制线程。
  • 它不是要帮助您编写更少的代码,而是要帮助您有一个统一的代码库设计。

原理

根据不同层的责任将应用程序的关注点分离,可以让您轻松拥抱变化并拥有更具弹性的软件结构。

不要一开始就创建完全的设计,而是采取一种可以允许项目演变的设计。

应用程序的详细信息(例如用户界面)应该依赖于业务逻辑,而不是反过来。

在整个应用程序中保持简洁和统一的架构设计,可以帮助提高生产力、重构和一般性维护。

动机

应用架构有很多种方式,如果一开始的总体架构不明显,开发者可能会为项目的不同特性创建不同的结构;但一开始就创建一个僵化的架构可能会更加有害,因为一段时间后,项目可能会与开发者最初设想的不同。

更糟糕的是,希望能够一开始就创建一个足够项目初期且永久适用的设计,已经被证明是相当复杂的,甚至可能导致项目走向失败。

在开始时决定在项目中实施何种架构很困难,因为大多数情况下项目会随着代码本身的发展而发展,在开始编写代码之前,很少了解应用程序的内部工作原理,因此对如何设计了解很少。

从一开始就决定一个非常复杂和僵化的架构可能会导致项目走向失败的深渊;架构越复杂,实施越难,而且哪怕最微小的变更都需要很大的努力,比如创建样板化的协议和委托,这些对于小型项目来说意义不大。

另一方面,一开始就决定一个非常基础的或没有架构的方法可能一开始是有用的,但一旦项目开始增长,结构就会达到极限并逐渐磨损。

这引出了一个大问题:什么是既可以用于小型项目又可以支持项目逐渐变大和复杂的好架构呢?

尽管在一个应用程序中拥有不同的架构不会直接对其功能造成伤害,但它肯定会影响维护,使重构或进行任何更改都变得困难。

  • 没有架构,你的代码就没有结构。
  • 没有项目经验,你不知道要实施什么架构。
  • 没有重构,代码开始腐烂和衰落。
  • 没有变更,你不能实现新的功能或修改现有功能。

适用性

任何针对 iOS 9 或更高版本编写的 Swift 应用。

无论你的应用只有一个屏幕还是几十个屏幕,Clean Architecture 都是大型和模块化项目的完美选择,但它的样板化非常低,即使是最简单的应用也可以从中受益。

理想情况下用于新项目,但也可能通过深入的重构在现有应用中实施。

单体和模块化项目可以从 Clean Architecture 中受益。

结构

干净的架构遵循依赖倒置原则

低层策略依赖于高层策略,而高层策略能够通过使用接口或协议来与低层策略通信。

最高层策略是您的应用领域,换句话说,是业务逻辑。

最低层策略是您的用户界面,即标签、按钮、图像等。

Structure

实现

安装

您可以使用 CocoaPods 获取干净的架构。

将其添加到您的 Podfile 中

pod 'CleanArchitecture'

安装和下载

> pod install

如果您想知道 CocoaPods 是什么,请查看:https://cocoapods.org.cn

表示器

表示器负责解析应用程序数据,以便将其呈现给用户。

应依赖于业务逻辑,并且不应了解 View 的任何具体内容。

它们通过 ViewModel 与 View 通信。

在新文件中导入 Clean Architecture

import CleanArchitecture

创建一个扩展 Presenter 的类

class MyPresenter:Presenter {
    
}

视图

视图负责用户界面层。

应了解表示器的一切,理想情况下,只与表示器交互,并且应用程序的任何其他层都不应依赖于视图,即这是面向用户的前线,也是抽象的底层。

在iOS中的应用通常涉及视图控制器之间的过渡,大多数情况下只有一个活动状态。

当你的视图被实例化时,它会创建你的视图模型(Presenter)和模型(ViewModel)的实例,相应地连接它们,并分配其责任。

如果你的视图被释放,视图模型和展示者(Presenter)也将被释放。

你可以将每个视图抽象为应用的一个区域或屏幕,每个视图都将有自己的视图模型,理想状态下,它们也将有自己的特定展示者。

视图继承自UIViewController。

在新文件中导入 Clean Architecture

import CleanArchitecture

创建一个继承自View的新类。

视图是一个泛型类,需要用展示者(Presenter)进行专业化。

class MyView:View<MyPresenter> {

}
  • MyPresenter 扩展展示者的你的类

视图模型(ViewModel)

要展示给用户的用户信息的结构。

展示者(Presenter)负责在需要时更新视图模型(ViewModel)。每个视图模型都可以有一个观察者,当属性变化时,它将通过闭包来通知;理想情况下,这个观察者应该是视图。

在视图模型(ViewModel)中,你可以定义任何你需要的东西,从基本类型如Bool或String,到更复杂类型如UIColor或UIImage,甚至是你自己的结构体。

你还可以决定你的属性是否可选。

在新文件中导入 Clean Architecture

import CleanArchitecture

创建一个新的结构。

struct MyViewModel {
    var userName = String()
    var buttonEnabled = false
    var buttonColor:UIColor?
    var icon:UIImage?
}

更新视图模型(Updating the ViewModel)

你的展示者(Presenter)负责更新视图模型(ViewModel),你可以决定何时更新,因为它是线程安全的,可以在任何线程上执行。

在你的展示者(Presenter)类中

func newUser(name:String) {
    var viewModel = MyViewModel()
    viewModel.userName = name
    update(viewModel:viewModel)
}

这样就可以了,当有更新的话,视图模型(ViewModel)将负责更新监听者。

监听视图模型(ViewModel)更新(Listening for ViewModel updates)

通常,你想让视图(View)监听视图模型(ViewModel)的更新。

监听更新是线程安全的,无论你的展示者(Presenter)在后台线程更新,你总会被在主线程上通知。

在你的MyView类中

func listenToUpdates() {
    presenter.viewModel { [weak self] (viewModel:MyViewModel) in
        self?.title = viewModel.userName
    }
}

演示

克隆或下载此仓库,它包含一个简单的演示应用程序,将帮助您清楚地了解如何实现清洁架构。