我目前正在使用Parse开发一个应用程序，我想开始抽象他们的SDK，因为我不知道我是否以及何时将他们的后端替换为另一个其他提供者或我们的。
另一个动机是分离问题：我的所有应用程序代码都将使用相同的框架，而我可以更新任何后端细节的框架。
我首先创建了一些通用类来替换它们的主类。此泛型类定义每个适配器必须实现的协议。然后，我有一个Parse适配器，可以将调用转发给Parse SDK。
我可以预测的一些问题是，这需要很多不同的类。在某些情况下，例如Parse，他们也有处理Facebook的课程。或者某些部分的架构可能如此不同，以至于不允许这样的事情发生共同点。
我实际上从未和Stackmob一起走得太远，因为我和Parse一样，所以我猜第一个版本将分享Parse自己的架构。
答案 0 :(得分：3)
我是Applicasa的开发者布道者。 我们为移动应用程序开发人员构建了一套很酷的工具，其中一部分包括提供与Parse，StackMob等相比采用不同方法的BaaS服务。我认为它提供了一个有用的视角，可以解决从第三方SDK API中抽象出来的问题，这种方式可以让您替换其他提供商或您自己的后端。 /免责声明
那里有类似的东西吗？我已经搜索过但没有成功，但也许我正在寻找错误的方向
虽然还有其他提供类似和差异化功能的BaaS提供商，但我并不知道那里的产品会以不可知的方式完全抽象出第三方提供商。
这类似的最佳做法是什么？
我认为你已经证明了在正确的方向上迈出坚实的基础。
首先，您在预测最终会得到许多不同的类时是正确的，这些类以后端无关的方式封装对象和所需的功能。当然，这个数字取决于你要追求的抽象和封装类型。你概述的方法听起来像我开始这样一个项目的方式，为我的应用程序需要与之交互的所有对象创建类，并在这些类（或它们都扩展的基类）上实现自定义方法这将完成与后端提供商进行交互的实际工作。
因此，如果我正在构建一个应用程序，例如，有一个Foo，Bar和Baz对象，我会将这些类创建为内部API的一部分，具有我的应用程序所需的所有必要功能。所有应用程序逻辑和功能操作只会与这些类进行交互，所有应用程序逻辑和功能都将是数据后端不可知（意味着内部功能不依赖于数据后端，但对象类将提供一致的接口，允许操作执行，同时保持数据处理方法私有。）
然后，我可能会使每个类继承自BaseObject类，其中包括与数据后端实际交谈的方法（基于提供程序或我自己的自定义远程后端）。 BaseObject类可能包含saveObject，getById:，getObjects等方法（带有一些用于执行对象过滤/搜索的适当参数）。然后，当我想在将来替换我的后端数据服务时，我只需要专注于更新处理数据交互的BaseObject类方法，而我所有的app逻辑和＆amp;功能与Foo，Bar和Baz类相关联，实际上并不关心如何在后台执行get / save / update / delete操作。
现在，为了让自己尽可能轻松，我会构建我的BaaS架构以匹配内部对象类名称（根据BaaS要求，我可以使用isKindOfClass:或{ {1}}致电）。这意味着如果我使用Parse，我想让我的NSStringFromClass:方法获取类名的save来执行数据操作。如果我使用的是像Applicasa这样的服务，它会生成用于数据交互的原生对象的自定义SDK，我希望在NSStringFromClass:结果上建立自定义数据操作。如果我想要甚至更多灵活性（可能允许使用多个后端提供程序，或者其他一些复杂的需求），我会让所有子类告诉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我希望这是有道理的。
我是否应该坚持使用Parse SDK，只是确保使用它的代码能够被很好地识别和包含？
像这样进行内部抽象将是一项相当多的工作，但它将不可避免地提供很多灵活性来实现。您可以实现CoreData，拒绝CoreData，并做任何您真正想做的事情。以数据无关的方式构建内部应用程序逻辑/功能有一定的优势，即使它允许您自己轻松尝试另一个BaaS，例如，应用程序代码的自定义分支，以了解您对另一个提供程序的喜好（或者为您提供开发自己的数据解决方案的简便途径。）
我希望有所帮助。
答案 1 :(得分：1)
我是StackMob的平台布道者并且认为我会在这个问题上发表意见。我们使用Core Data接口构建了iOS SDK。您将使用常规Core Data，我们已覆盖NSIncremental Store以持久存储到StackMob而不是SQLLite。
您可以查看核心数据代码的示例 http://developer.stackmob.com/tutorials/ios/Create-an-Object
如果您想查看Core Data正在利用哪些方法与StackMob进行通信。 http://developer.stackmob.com/tutorials/ios/Lower-Level-CRUD-API