Tag: 模块
将您的iOS应用程序网络层重构为模块
在每个项目上，总是需要改变核心服务。 这可能是由于不同的原因，对我们使用的库所做的更改，第三方/ Apple库上不推荐使用的方法，或者我们只是想迁移以开始使用新的库或API。 这种“小”变化可能会影响我们的开发速度，可能需要大量时间才能完成和/或可能会引入错误。 我们会做什么 在本文上，我们会将所有与网络相关的文件重构为一个模块。 然后，将网络服务和所有相关类迁移到动态库中，最后将使用URLSession更改为Alamofire 。 你需要知道的 要继续阅读本文，您需要熟悉以下内容： Cocoapods（您可以在此处阅读有关Cocoapods的更多信息） URLSession （很高兴知道） Alamofire （ Alamofire知） 即使您不熟悉最后两个库，您仍然可以利用本文。 初始点 您可以从这里获得本课程的起点材料。 第一 打开.xworkspace （或.xproject ，此时不起作用）并运行（ command + R ）。 该应用程序非常简单； 它可以让您搜索艺术家并显示其所有专辑，仅此而已。 简单直接。 现在，我们已将应用程序设为初始状态，让我们开始向项目添加动态库。 单击项目导航器顶部的项目。 现在，在“目标”窗口中，单击左下方的加号（+）。 现在一直向下滚动，直到到达“框架和库”，选择“ Cocoa Touch Framework”，然后单击“下一步”。 现在输入名称（我叫我的NetworkService），然后单击“完成”。 创建框架后，您应该在“目标”窗口和“常规”选项卡的“链接的框架和库”上看到它。 第二 现在我们有了框架，让我们将与网络服务相关的所有类移到新创建的名为“网络服务”的文件夹中（或者您将其称为框架） 太好了，现在，如果您运行该应用程序，则会在视图控制器上注意到一些错误。 修复此错误非常简单，只需在视图控制器上import NetworkService 。 再次运行该应用程序，它应该可以正常运行。 太好了，我们只是模块化了我们的网络服务。 第三 现在，该项目正在使用URLSession处理所有网络调用。 随着项目的增加或时间的推移，由于Cocoa Touch API或第三方库的更改，很有可能需要重构，更改或改编代码。 现在，让我们重构网络管理员以使用Alamofire代替URLSession 。 我们需要做的第一件事是更新Podfile […]
许多面孔的VIPER-第1部分
我最喜欢的是蓝色。 如此宏伟的生物……。 虽然如此，尽管他是一位伟大的自然爱好者，拥有所有的生物，但我对动物学的了解不足，不会让我进一步感到羞耻。 当然，我将谈论VIPER客户体系结构。 这个故事不是另一个“ iOS上的VIPER简介”或当前其他任何地方。 我相信我们有很多有关该主题的文章。 假定您了解该概念并具有一定的经验。 这也不是要将其与任何其他架构方法或架构进行比较。 我之所以选择它，是因为它确实代表了一种相对较好的“ 清洁体系结构”方法，并且遵循SOLID原则，可以承受。 我什至不会自己使用首字母缩写词，但是我想它使我们所有人都更容易理解该主题。 这个故事是关于以更多样化的方式展示VIPER，并展示其友好的面孔。 为此，我将首先处理一些神话，然后再讨论一些问题，考虑真正的问题，下一次我们将研究一个演示项目，该项目将作为一个可能的解决方案/答案。 误区1：VIPER有很多课程 可以？ 您认为应该有几节课？ 或更准确地说：您希望在代码中包含多少“ 单一职责原则” ？ 也许所有这些都值得商bat。 即使采用SR原则，我们也可以很快就某个特定类的职责进行辩论。 例如，Microsoft在MVVM的定义中将视图模型视为胶水代码 ，作为业务逻辑和视图之间的中间人。 有人可能会争辩说，这种职责范围太广：处理事件，表示逻辑并将模型数据转换为易于查看的形式应视为单独的职责。 关键是：无论采用哪种体系结构，如果要使代码可维护且可靠，那么它将必须符合“干净代码”的许多范式，其中包括SR，小类，尽可能少的耦合，OO模式，全部资金。 ……所有这些都导致“……很多课程……” 。 误解二：僵硬，有很多样板代码 我记得几年前，当我第一次接手VIPER并接管现有项目时，这并不是最好的体验。 不是因为VIPER本身，而是因为与该概念的明显斗争。 我实际上看到了我在这里所说的一个神话： 每个模块都需要很多样板代码 很多时候，这些类都没有创建，只是为了“遵循方法” 开发人员努力地采用需求的逻辑以使其适应VIPER规范，这当然是行不通的，并导致一些严格的遵循并同时破坏它的怪异组合。当我说“破坏”时，我真的这意味着从破坏模块的封装为一的角度来看。 演示者或路由器双向连接太多对象，并使每个结构更改都成为真正的PITA。 我们将在稍后的演示项目中看到，如果您牢记这一点，则不必一定是这样： 您需要遵循的是VIPER所基于的SOLID和其他OOP原则，并据此，您应该创建适合您工作的类。 尽可能在协议扩展，抽象类甚至父类（如果不是太多！！）中实现样板 误区3：学习困难，仅适合高级开发人员 VIPER就像学习SOLID，TDD和OOP设计模式一样困难。 等等…但这还是我们要做的，不是吗？ 好的，我也可以添加FRP 。 但是没关系，您的意思是：如果您想成为一名真正的高级开发人员，那么您必须学习上述知识，在这种情况下，您应该编写VIPER编码就像将比萨饼切成小块并撒上手工啤酒一样简单。选择。 是的，但是是初级人员……好吧，那么，如果您的初级同事没有采用VIPER风格，那么您的代码库将采用初级人员的技能组吗？ 如果是这样，那么是的，VIPER仅适合高级开发人员。 但是，在我曾经工作过的大多数地方，我们都确保初中生由年长者通过代码进行培训，而并非相反：采用代码以适应最高的通用技能水平…… 误解四：与SDK规定的MVC基础架构配合使用时，效果不佳 我想我在面向模块的体系结构系列中再次揭穿了这一点，特别是在第6部分：超越MVC中。 您也有类似Uber RIB的框架，也可以解决该问题，但是我不得不承认，我个人认为不应将体系结构转变为即时框架解决方案，但这是重点。 误解5：不适合小型项目或原型 同样，在面向模块的体系结构系列中，我们可以看到VIPER类完全精简和小巧，因为大多数样板都在协议扩展中实现。 如果您遵循神话2中所述的方法，那么即使在小型项目和原型中，您也会发现它非常易于使用并且可以快速实现任何种类的特定功能。 […]
