Swift中的数据源…或如何避免这种新的时尚持久性框架决定了您应用的架构

该帖子最初发表在dcordero.me中。在这里，您将始终找到更新的版本。

在iOS的世界中，确实有很好的框架来处理数据的持久性。

例如，Core Data是Apple提供的出色解决方案，即使在处理大量数据时也能提供令人难以置信的出色性能。但是也有其他一些替代方法出现。这些选择之一是Realm，据说它以更简单的语法提供比Core Data更好的性能。

但是可悲的是，在这个持久性世界中，没有什么能像预期的那样精彩。还有很多问题。我对Core Data，Realm或其中许多其他流行的持久性框架有非常不好的经验，这当然不仅是因为框架本身，还因为它们是如何应用于项目的。

主要问题在于，由于这些框架解决的问题非常复杂，因此它们倾向于具有相当复杂的语法。而且，如果框架的范围没有明确定义，那么最终它们的对象往往会散布在整个项目中，找到从NSManagedObjects获取数据的UIView，使用RLMObjects填充单元的UICollectionViews等。

这种情况永远都不会发生，应用程序的持久性应该是非常内部的东西，应该隐藏在应用程序核心部分的最深层中，当然也不要与我们的UI层产生冲突。最重要的部分是，将来替换掉所有这些代码部分以使用任何其他解决方案或框架应该非常容易。

这听起来像乌托邦，对吗？但是……我们如何得到这个？我们基本上只需要一个抽象解决方案，该解决方案定义一个接口来处理数据的持久性。我的意思是使用数据源 。

注意：请不要将此数据源的概念与iOS用于填充某些TableViews，CollectionViews等的数据源混淆。

数据源从核心业务逻辑中提取持久性逻辑，并且无论框架的具体细节如何，都可以访问数据。

我们可以在Swift中使用非常简单的协议构建一个接口来管理数据源，该协议提供了完整的CRUD（创建读取更新删除）接口。

作为免责声明，我想在示例中保持简单，但是您是否听到了`BooksRealmDataSource`？没有？仿制药真的大声尖叫，不是吗？ 🙃

现在，我们不必担心框架…想象一下让您的App的所有数据源实现先前协议的情况。

我的意思是，无论最终来自何处，总是以完全相同的方式访问信息。磁盘，内存甚至网络。它们全部来自完全相同的协议。

构建一个存储库 模式非常容易，该存储库 模式通过不同的数据源进行迭代可以从每种情况下从最快或更合适的源获取数据。

我们的存储库的实现再次要求泛型，只是收到泛型应管理的数据源列表以及适用于它们的策略。

例如，在上一个示例中，要获取我们的图书清单的存储库可能具有3个不同的数据源：内存，磁盘和网络。具有首发比赛的策略。

但是用于进行用户登录的存储库将只有一个数据源（网络），以确保我们始终通过后端验证凭据。

最后，从应用程序的其余部分开始，这意味着无论数据来自何处，或内部使用了哪些框架，都使数据如魔术般神奇。正是我们想要的数据。

就像我说的，最好的部分是，遵循这种模式，我们获得了巨大的模块化，并且我们可以在需要时很容易地更改内部实现。您想尝试一下X新的流行框架吗？好吧，只需更改您的一个数据源的实现，该应用程序的其余部分将完全不需要任何更改。