5

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

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

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

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

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

  • 这样的最佳实践是什么？
  • 外面有这样的东西吗？我已经搜索过但没有成功，但也许我看错了方向；
  • 我应该坚持使用 Parse SDK 以确保使用它的代码得到很好的识别和包含吗？
4

2 回答 2

3

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

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

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

这样的最佳实践是什么？

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

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

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

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

现在，为了让自己尽可能轻松，我将构建我的 BaaS 模式以匹配内部对象类名称（根据 BaaS 要求，我可以使用 anisKindOfClass:或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，以了解您对另一个提供商的喜爱程度（或为您提供开发自己的数据解决方案的简单途径）。

我希望这会有所帮助。

于 2013-01-03T05:59:56.977 回答
1

我是 StackMob 的平台宣传员，我想我会加入这个问题。我们使用 Core Data 接口构建了我们的 iOS SDK。您将使用常规的核心数据，并且我们已经覆盖了 NSIncremental 存储以持久保存到 StackMob 而不是 SQLLite。

您可以查看 Core Data 代码的示例。
http://developer.stackmob.com/tutorials/ios/Create-an-Object

如果您想查看 Core Data 使用哪些方法与 StackMob 进行通信。 http://developer.stackmob.com/tutorials/ios/Lower-Level-CRUD-API

于 2012-12-17T21:27:44.907 回答