为BeaaS创建包装器(Parse/Stackmob/...)

Question

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

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

我首先创建了一些泛型类来替换它们的主类.此泛型类定义每个适配器必须实现的协议.然后我有一个Parse适配器,可以将调用转发给Parse SDK.

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

我实际上从未和Stackmob一起走过这么远,因为我和Parse一样,所以我猜第一个版本将分享Parse自己的架构.

• 对于这样的事情,最佳做法是什么？
• 那里有类似的东西吗？我已经搜索过但没有成功,但也许我看错了方向;
• 我应该坚持使用Parse SDK,只是确保使用它的代码能够被很好地识别和包含吗？

Answer 1

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

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

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

对于这样的事情，最佳实践是什么？

我认为您已经为朝着正确的方向开始奠定了坚实的基础。

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

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

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

现在，为了让事情尽可能简单，我将构建 BaaS 架构来匹配内部对象类名称（其中，根据 BaaS 要求，我可以使用 orisKindOfClass:调用NSStringFromClass:）。这意味着如果我使用 Parse，我想让我的save方法获取NSStringFromClass:类名来执行数据操作。如果我使用像 Applicasa 这样的服务，它会生成用于数据交互的本机对象的自定义 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";
}

我希望这是有道理的。

我是否应该坚持使用 Parse SDK 只是确保使用它的代码得到很好的识别和包含？

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

我希望这有帮助。