objective-c - 为 BeaaS 创建一个包装器(Parse/Stackmob/...)

Question

我目前正在使用 Parse 开发一个应用程序，我想开始抽象他们的 SDK，因为我不知道我是否以及何时将他们的后端替换为其他提供商或我们的后端。

另一个动机是分离问题:我所有的应用程序代码都将使用相同的框架，而我可以只针对任何后端细节更新框架。

我首先创建了一些通用类来替换它们的主要类。这个通用类定义了每个适配器必须实现的协议(protocol)。然后我有一个 Parse 适配器，可以将调用转发到 Parse SDK。

我可以预测的一些问题是这将需要很多不同的类。在某些情况下，例如Parse，他们也有处理 Facebook 的类。或者某些部分的架构可能如此不同，以至于没有共同点来允许这样的事情。

实际上，我从未像使用 Parse 那样使用 Stackmob，所以我猜第一个版本将共享 Parse 自己的架构。

此类事情的最佳做法是什么？

有这样的东西吗？我已经搜索过但没有成功
也许我看错了方向；

我应该坚持使用 Parse SDK 只是确保代码使用
它被很好地识别和控制？

Answer 1

我是 Applicasa 的开发人员布道师。
我们为移动应用程序开发人员构建了一组很酷的工具，其中一部分包括提供 BaaS 服务，与 Parse、StackMob 等相比，该服务采用了一些不同的方法。我认为它提供了一个有用的视角来解决从第三方 SDK API 中抽象出来的问题，这种方式允许您用其他提供商或您自己的提供商替换后端。
/免责声明

Is there something like this out there? I've already searched without success but maybe I'm looking in the wrong direction

虽然还有其他 BaaS 提供商提供类似和差异化的功能，但我不知道有一种产品以不可知的方式完全抽象出第三方提供商。

What are the best practices for something like this?

我认为您已经显示出在朝着正确方向开始的坚实基础上。

首先，您正确地预测最终会得到许多不同的类，这些类以后端不可知的方式封装对象和所需的功能。当然，数量取决于您所追求的抽象和封装类型。您概述的方法听起来也像我开始这样一个项目的方式——为我的应用程序需要与之交互的所有对象创建类，并在这些类(或它们都扩展的基类)上实现自定义方法这将完成与后端提供程序交互的实际工作。

因此，如果我正在构建一个应用程序，例如，具有 Foo , Bar , 和 Baz对象，我将创建这些类作为我的内部 API 的一部分，具有我的应用程序所需的所有必要功能。所有应用程序逻辑和功能操作只会与这些类交互，并且所有应用程序逻辑和功能都与数据后端无关(意味着没有内部功能可以依赖于数据后端，但对象类将提供一致的接口(interface)，允许操作执行，同时保持数据处理方法私有(private))。

然后，我可能会让每个类都继承自 BaseObject类，其中将包括实际与数据后端(基于提供者或我自己的自定义远程后端)通信的方法。 BaseObject类可能有类似 saveObject 的方法, getById: , getObjects (带有一些用于执行对象过滤/搜索的适当参数)。然后，当我以后想更换我的后端数据服务时，我只需要专注于更新 BaseObject处理数据交互的类方法，而我所有的应用程序逻辑和功能都与 Foo 相关联, Bar , 和 Baz类，并且实际上并不关心 get/save/update/delete 操作在幕后如何工作。

现在，为了让事情尽可能简单，我将构建我的 BaaS 模式以匹配内部对象类名称(其中，根据 BaaS 要求，我可以使用 isKindOfClass: 或 NSStringFromClass: 调用)。这意味着，如果我使用 Parse，我想制作我的 save方法获取 NSStringFromClass:执行数据操作的类名。如果我使用 Applicsa 之类的服务，它会生成用于数据交互的 native 对象的自定义 SDK，我希望将自定义数据操作基于 isKindOfClass:。结果。如果我什至想要 更多 比这更灵活(可能允许使用多个后端提供程序，或其他一些复杂的要求)，我会让所有的子类告诉 BaseObject通过某种自定义方法(例如 getSchemaName)用于数据操作的确切模式名称.我可能会将它定义为 BaseObject默认情况下将类名作为字符串返回的方法，然后在子类上实现以进一步自定义。所以，里面有一个 BaseObject save方法可能如下所示:

- (BOOL) save {
  // call backend-specific method for saving an object
  BaasProviderObject *objectToSave = [BaasProviderObject
                                      objectWithClassName:[self getSchemaName]];

  // Transfer all object properties to BaasProviderObject properties
  // Implement however it makes the most sense for BaasProvider

  // After you've set all calling object properties to BaasProviderObject
  // key-value pairs or object properties, you call the BaasProvider's save
  [objectToSave save];

  // Return a BOOL value to indicate actual success/failure
  return YES;  // you'll want this to come from BaaS
}

然后在，比如说， Foo类，我可能会实现 getSchemaName像这样:

- (NSString) getSchemaName {
  // Return a custom NSString for BaasProvider schema
  return @"dbFoo";
}

我希望这是有道理的。

Should I stick with the Parse SDK just making sure that the code using it is well identified and contained?

进行这样的内部抽象将需要大量的前期工作，但它不可避免地会提供很大的灵活性来实现您的愿望。您可以实现 CoreData，拒绝 CoreData，并做您真正想做的任何事情。以与数据无关的方式构建内部应用程序逻辑/功能有明显的优势，即使它让自己可以轻松地在应用程序代码的自定义分支中尝试另一个 BaaS，以了解您对另一个提供商的喜欢(或为您提供一条轻松的途径来开发您自己的数据解决方案)。

我希望这有帮助。