Tag: Ios体系结构

IOS中的VIP（干净的Swift架构）

VIP还鼓励使用模板“促进”其实施。您可以在Clean Swift IOS体系结构上找到模板，以及有关VIP生命周期的更多详细信息。 使用这些模板，您无需担心项目中VIP架构的实现。 模板有助于轻松编写测试用例。 VIP单向方式 VIPER双向方法 在上图中，我们可以看到VIP架构采用的是单向方法，与VIPER有所不同，后者遵循的是双向方法。这两种架构均基于Single Responsibility Principle（单一责任原则），可带来整洁的架构和更好的可测试性。 如何在项目中使用VIP模板 首先从干净的Swift架构下载模板 将干净的swift文件夹复制到/ Users / / Library / Developer / Xcode / Templates / File \ Templates 启动Xcode并创建一个新文件（文件>新建>文件或⌘N） 搜索Clean Swift部分，然后在可用模板之间进行选择 这样，您就可以轻松地在项目中实施VIP架构。 同样，VIP模板具有用于单元测试实施的模板。 众所周知，VIP完全支持TDD（测试驱动开发）。您不必担心为项目编写单元测试类。 VIP演示项目 如果您对它在现实生活项目中的实施更加困惑，我在Github项目中对VIP架构做了简单的演示。 关于项目中的实施以及单元测试的实施，以便您可以开始遵循项目中的TDD（测试驱动开发）。 VIP架构实施 VIP不仅由三部分组成，尽管其名称仅是VIP，但它不仅具有ViewControllers，Interactors和Presenters等更多的组件，例如数据模型，路由器和Workers，而且可以将Viewcontrollers划分为Configurator。变得庞大。 ViewController 在ViewController的viewDidLoad() ，我们需要运行一些业务逻辑，因此我们将其称为fetchPosts() 。 在fetchPosts() ，我们在输出（交互器）上调用fetchPosts(request) ）。 而已。 我们要求输出执行我们的业务逻辑。 视图控制器不需要也不应该关心谁以及如何完成。但是，如果有必要，可以将ViewController划分为Configurator。 互动者 交互器包含您应用程序的业务逻辑。 用户在您的UI中点击并滑动即可与您的应用进行交互。 视图控制器从UI收集用户输入，并将其传递给交互器。 然后，它检索一些模型，并要求一些工人进行这项工作。 工人 帖子视图可能需要从Core […]

iOS体系结构：MVVM

到目前为止，在软件开发中，MVC已成为最受欢迎的体系结构之一。 它已在每个网站，桌面或移动应用程序中使用。 但这是针对iOS应用程序的优化解决方案吗？ 首先，让我们谈谈什么是iOS架构的良好设计？ 在具有严格角色的实体之间均衡分配职责。 可测试性通常来自第一个功能（不用担心：使用适当的体系结构很容易实现）。 易于使用 ，维护成本低。 让我们再次谈论MVC定义。 MVC代表模型-视图-控制器。 模型：用于表示数据及其周围的一些逻辑。 视图：代表用户界面（UI）。 控制器：模型和视图之间的中介者。 它从View接收事件以修改Model并根据Model的更改更新View。 在这里，由于Controller是View和Model之间的中介，所以他们彼此之间并不了解。 这样好吗 在iOS中，模型可以是用于存储数据的NSObject类。 查看可能的UIControl，例如UIButton，UILabel，UITextField等。最后，Controller是UIViewController的子类。 等等，我说的是“查看”-控制器。 是的，不仅是控制器。 在Cocoa MVC中，Controller参与了View的生命周期。 UIViewController甚至是UIView的子类。 UIViewController处理用户在UI上的大部分交互，并且负责将数据从模型绑定到视图。 ViewController做很多事情：获取数据，显示UI，自定义动画等等。随着时间的推移，ViewController将成为大量的视图控制器。 您的代码将变得一团糟，很难阅读，调试和测试。 MVC仍然适合小型应用程序，但是，当您的项目越来越大时，实现单元测试是一项艰巨的任务，因为这些模块紧密耦合。 因此，我们需要尽可能地分离控制器，视图和模型，这是MVVM的需求。 MVVM：模型—视图— ViewModel 这里有什么新消息？ ViewController与Model分开。 ViewModel现在是拥有模型的人，负责处理大多数应用程序逻辑，包括绑定数据，更新数据，获取数据等等。 从ViewController进行的所有数据访问都必须通过ViewModel。 现在，ViewController将处理用户的交互，显示数据并进行一些动画处理。 ViewController被视为View。 让我们通过一个简单的应用程序来详细了解。 用户界面只有1个表格，该表格将获取并显示一些漂亮女孩的照片。 这是我们的模型，它存储数据，并对这些数据有一些逻辑 ViewController有一个ViewModel将从服务器获取数据 ViewController将使用ViewModel来获取数据 从ViewController对Model的所有访问都必须通过ViewModel View（GirlCell）将使用一些参数通过函数将数据绑定到UI上显示 结果如下： 这只是一个演示，因此请忽略我难看的UI。 总结： IMHO，MVC或MVVM，甚至VIPER都有其优缺点。 决定要在应用程序中使用哪种架构取决于许多因素：目的，应用程序的大小，甚至是应用程序的潜力，……如果您要构建一百万个用户的应用程序，并且您的团队可能多达20人，那么应该是MVVM或VIPER。 但是，如果这只是展示您做某事的能力的一个小演示，请不要过多使用那些复杂的结构。 简单点，就是MVC。 结帐演示代码： https : //github.com/dzungnguyen1993/MVVM-Sample 在此演示中，我将Swift […]

iOS体系结构：MVVM-C，场景（2/6）

场景可以被认为是应用程序内部的section ， feature或用例 。 一个很小但是内部完整的包含整个应用程序的一部分。 您要制作场景的大小取决于您。 我通常会发现将场景定义为功能非常有效。 它通常是1到4个屏幕的集合，旨在实现一个单一的目的。 例如登录流程，图片上传过程或购买渠道。 首先，我在Xcode项目中创建一个名为Scenes的文件夹，其中将包含所有场景的子文件夹。 在一个特定场景内（如您在下面的“ 搜索”示例中可以看到的），我拥有与该场景有关的所有部分。 从协调员到视图。 这些文件夹结构将针对每个场景重复。 我认为这有助于将应用程序的每个场景划分为更大的整个应用程序中的完整的独立设备。 我可以将这个场景的文件夹拖到另一个应用程序，它应该可以正常工作。 从上面的屏幕快照中可以看到，每个场景都应该有自己的故事板 ，并且与场景名称相同。 在iOS社区中，故事板仍然是一个有争议的话题。 有些人无法想象不使用情节提要来创建iOS应用程序，而社区中的其他一些人不会因为使用情节提要而陷入困境。 他们要么以编程方式创建视图，要么仅在每个屏幕上使用XIB。 对情节提要板的抱怨之一是，有时开发人员会将其应用程序的所有屏幕都塞进一个大型情节提要板中，这变得一团糟，尤其是当有多个人在同一个情节提要板上工作时。 一定喜欢那些无法理解的GIT合并冲突，在这些冲突中，您必须解析XML文本以了解正在发生的事情。 但是使用情节提要板仍然有很多好处。 它们使尺寸分类和自动布局变得轻而易举，它们允许静态表视图，它们使您可视化应用程序的流程等。 我不会在这里介绍使用情节提要的所有优点和缺点，但是我想我已经找到了中间立场。 每个场景都应该有一个情节提要，其中仅包含该场景中包含的ViewController。 这对于防止合并冲突大有帮助，因为通常只有一个开发人员正在开发应用程序中的特定功能或部分。 最重要的是 ，尽管我确实使用情节提要的面板来包含每个场景的ViewController，但我并未在情节提要上设置任何顺序或关系。 它仅用于为特定场景中包含的每个ViewController配置视图。 这一点很重要。 我们可以使用情节提要，但不能使用segues或可以使用界面生成器创建的任何其他类型的关系。 原因是协调器将负责处理导航和ViewController之间的关系。 许多人认为协调器和情节提要不能并存。 实际上，如果您不使用搜寻或关系，它们可以很好地协同工作。 有关协调员的更多信息，请继续阅读本系列的下一篇文章： iOS架构：MVVM-C，协调器（3/6）

iOS体系结构：MVVM-C，服务（6/6）

服务层是已经存在了数十年的设计模式。 它基于这样一个概念，即系统应分为不同的层（例如洋葱），每个层的每个层都有不同的职责。 服务层应该是与外界的连接，无论是数据库，远程服务器，蓝牙连接等。 在该服务层中，应该有多个服务，并且每个服务都应承担处理特定种类的服务或资源的单一责任。 基本上就是这样，它实际上是一个简单的概念，我们可能已经在我们的应用程序中以某种方式使用了它。 例如，我们通常有一个ApiClient类，该类处理服务器上的REST API。 但是我想指出的是，这与我们在整个系列中一直在构建的体系结构非常吻合的原因在于，我们应该组织和构造该层以充分利用它。 让我们继续研究ApiClient示例。 我们所有人都可能已经熟悉ApiClient的概念。 我们基于Apple的URLSession或其他框架构建一个负责发出HTTP请求的对象。 但这应该是它的唯一责任。 它应该不了解我们的模型和业务逻辑。 因此，如果所有这些业务逻辑都不能在ApiClient中，并且最肯定也不应在我们较低的ViewModel / View层中，应该去哪里？ 这就是服务层的所在。 服务通常会包裹某种客户端（在本例中为ApiClient），并在其之上添加所有模型解析和业务逻辑。 我们可能很想创建一个ApiService来处理我们应用程序中的所有API需求，并且在一个非常简单的应用程序中它可能会起作用。 但是，我建议我们按逻辑单元来分隔服务（即使它们与本示例中的同类）相同。 例如，您可能具有一个用于处理登录/注册的SessionService和一个用于将图片张贴到服务器的PostService 。 这样，当向ViewModel注入服务时，它需要的是获取仅处理应用程序特定部分需求的特定服务 。 同样， SRP 。 这是一个非常简单的服务的缩写示例。 让我们在API上搜索位置的PlaceService 。 我们从一个概述操作的协议开始，我们将在此服务上调用该操作。 在这里拥有一个协议确实很有用，因为我们可能想要切换执行相同操作但使用不同来源（例如不同的API或缓存）的实现。 或者，与以往一样，它使测试变得更加容易。

iOS应用架构介绍

什么是建筑？ 这个词实际上是什么意思？ 如果您查看字典，则有两个主要定义。 设计或建造建筑物的艺术或实践 事物的复杂或精心设计的结构。 第一个定义是我们大多数人最熟悉的定义，它是设计建筑物（或任何其他类型的结构）。 例如，在实际建造房屋之前，您必须设计房屋的建造方式。 您必须设计外观，工作方式，哪些门将通向哪些房间，支撑梁将在何处等等。 这引出了第二个定义： 事物的复杂或精心设计的结构。 这采用了与以前相同的想法，并在更广泛的意义上应用了它。 这是经过精心设计的事物结构。 我们在这里要谈论的是软件 。 令人难以置信的是，没有蓝图，没有任何计划或设计的人就会开始盖房子。 显然，在开始建造房屋之前，您需要考虑周全，设计合理的蓝图，该蓝图应遵循标准的行业模式。 造成这种情况的众多原因之一是，在房屋建造（或中途建造）之后，即使不是不可能，也很难回去改变房屋的基本结构。 另外，如果您没有蓝图或设计，我只能想象房子的一塌糊涂，到处都是矛盾和惊奇。 同样适用于软件。 我们应该设计系统，以便对将要拥有的高级结构，它们之间的关系以及每个结构的输入/输出有一个想法。 这将使我们的系统易于推理和理解。 不可避免地会发生软件系统的变化，因此，如果我们拥有可靠的体系结构，则更改软件系统的特定模块应该很简单，而不必更改整体的高级结构。 软件体系结构是关于做出基本的结构选择，一旦实施，更改成本很高。 那么，这一切如何适用于iOS应用程序？ 因此，让我们从基础开始。 如果不谈论模型视图控制器（MVC），就无法谈论iOS体系结构。 MVC于70年代在Xeroc Parc发明，最初出现在编程语言Smalltalk-80中。 这是一个非常简单的体系结构，它将软件系统中的所有对象分为三个存储区。 这些可能会有所不同，具体取决于您正在使用的域，但是对于iOS，可以这样描述： 模型 ：涉及存储数据，传输数据以及数据本身的任何事物。 视图：任何在屏幕上显示内容并处理用户输入的用户可见对象。 控制器：模型与视图之间的中介者。 控制器更新模型，然后模型通知控制器有新数据。 然后控制器更新视图，并且视图发送所有用户操作 在iOS中无法绕过MVC。 可以显示在屏幕上的UIView的所有子类都是您的视图，控制控件并拥有这些UIView的UIViewController的所有子类都是控制器。 基本上，其他所有东西都是模型。 因此，从某种意义上说，MVC是苹果公司处理iOS / macOS / tvOS / watchOS应用程序体系结构的“官方”方式。 如果最后一段中的内容听起来有些不对劲，则可能是您遇到了一些麻烦。 在许多情况下，“ 基本上所有其他一切都是模型 ”这句话是正确的。 至少在一个简单的应用程序中，其他对象将是数据模型，数据库或服务器/ API访问对象，而这些是模型。 但是，这里存在MVC的问题。 假设一切都将是Model或View或Controller太简单了，就是这样。 没有其他责任的对象。 […]

iOS体系结构：MVVM-C，简介（1/6）

这将是六篇系列文章中的第一篇，详细介绍我的MVVM-C iOS应用程序体系结构模式的特定实现或风格。 如果您想全面了解iOS世界中的不同体系结构，请查阅我以前的文章。 它是Model-View-ViewModel体系结构以及Coordinator模式的组合。 我的具体实现比这更多，但是技术世界不需要任何更长和更复杂的初始化。 MVVM-C已经存在，因此我将在此基础上进行构建。 我建议仔细阅读它们，以使其最有意义。 1. 简介 （您在这里） 2. 场景：在这里，我将讨论场景的概念以及为什么我认为根据此概念对应用程序进行模块化很重要。 这也可以称为“用例”。 3. 协调器 ：我将研究FlowCoordinator模式的实现，它与应用程序的Scenes的关系。 4. ViewModel ：在这里，我谈论我著名的MVVM体系结构的实现，在我看来，它只是体系结构整体中很小但很重要的一部分。 5. ViewData ：这是我认为对实现此体系结构确实很重要的两个概念中的第一个，但我认为不需要将其添加到名称中，MVVM-C-VD会很混乱。 这是与ViewModel相关的概念，但有些不同。 6. 服务 ： MVVM-C-VD-S会更糟！ 因此，它也不包含在名称中，但我认为它也很重要。 如果您已经了解了服务层模式，那么您就会知道我在说什么。 我将详细介绍该模式的具体实现以及它如何适合整个模式。 这就是整体架构的外观。 如果您不了解每个部分的功能，请不要担心，一旦我们到达本系列的结尾，就可以说一切都有意义。 继续阅读该系列的下一篇文章： iOS体系结构：MVVM-C，场景（2/6）