带流量控制器的MVVM —第一步

我正在观看有关MVVM概念的KrzysztofZabłocki的视频，并认为只有一种方法可以理解某些内容：创建我的项目！

在深入了解应用程序体系结构之后，最近6个月我一直在研究带有MVVM协议的模型。 要了解其起源，必须引用Natasha The Robot的文章以及有关面向编程协议的所有知识。 如果您不知道我在说什么，那么好的主意是阅读Natasha The Robot 。

一个月前，我最终观看了Steve“ Scotty” Scott的MVVM-C讲座。 在我今年看过的最好的视频之一中，重要的防御不是缩写技术，而是架构可以帮助我们改进软件的。 对于捍卫技术“银弹”的人们，我没有什么反对的态度，但是我更喜欢这样一种策略：从每个创意中汲取最大的价值，以找到最佳的解决方案。

Flow的初始化程序将构建ViewModel和Model（如果需要，还可以创建更多模型）和start方法，并创建必要的接口并注入其依赖项。 这将使这些实体之间的耦合更多地利用代码。 我们可以看到在OwlsFlowController的情况下，通过配置选择是将数据显示为Grid还是List，在这种情况下，它是固定的，但它可能是测试简单的A / B。

此模型的优点是，大多数列表中的应用程序共享相同的行为和相同的接口基础结构。 在这种情况下，只有数据和单元格会更改，并且可以作为参数传递并为所有列表创建重用代码库。

这里一个有趣的想法是实现了两种响应协议：一种用于Grid，一种用于List。 但是两者的实现是相同的。 这很有趣，因为我对每种类型的接口都有单独的操作，但是可以共享常用操作。 并且不使用继承。

界面的实现清晰明了，它是一种客观的基础结构，具有简单的参数即可显示。 所有创建都被删除，使他没有任何业务实现。

另一件事是通过Closure填充了单元格，这将使我们能够在不久的将来传递使用哪个手机作为参数。 这种体系结构的思想是将接口分为两部分，第一部分是一系列现成的基础架构，可在整个项目中重用。

第二部分是针对每种情况和每种数据集定制的UIView和单元格。 因此，我们的大部分界面都已包含在通用测试中，从而提高了安全性。

PS：由于某些原因，在某些情况下，Swift不会接受Generic类型作为init方法的协议参数。 仍在调查Swift Bug或故意限制。

结果是非常干净的代码，并最大程度地重用了接口。 并探讨了泛型和协议作为抽象问题的一种方法。 其他结果是构建时间明显快得多。

这些是几周后的初步结果，我希望获得其他结果，并将在其他文章中进行探讨。 如果他们想继续关注Github，请尝试在“ Middle”（此处）或“ Medium”（此处）的此处进行很好的记录，我将把这些文章。

接下来的步骤，谢谢。

下一步

• 测试：带有模拟对象的单元测试和UITest（MVVM和测试）
• 展开模型：其他对象（我需要找到其他动物）
• 接口的基础结构：创建其他单元格类型并使用相同的UIViewController

我的下一篇文章将介绍如何构建有效且易于维护的测试。 为我交叉手指。

特别感谢

引用时，我试图标记所有阅读的内容，以写出这段代码，对不起，如果我忘记了别人。

我不能忘记感谢Mikail Freitas帮助我识别了通用协议的初始化错误。 我们永远不会理解为什么在一种情况下有效而另一种无效。

PS：Claire Knight（Twiter），她将项目迁移到Swift 3和更多其他更新，以迅速增加API。 非常感谢。