我目前正在使用Parse开发一个应用程序，我想开始抽象他们的SDK，因为我不知道是否以及何时将他们的后端替换为其他提供商或我们的另一个。
另一个动机是分离问题：我所有的应用程序代码都将使用相同的框架，而我可以根据任何后端细节更新框架。
我首先创建了一些泛型类来替换它们的主类。这些泛型类定义了每个适配器必须实现的协议。然后我会有一个Parse适配器，它会将调用转发到Parse SDK。
我可以预测的一些问题是，这将需要很多不同的类。在某些情况下，例如Parse，他们也有处理Facebook的类。或者，某些部分的架构可能会如此不同，以至于没有共同点来允许这样的事情发生。
事实上，我从未像使用Parse那样使用Stackmob，所以我想第一个版本将共享Parse自己的架构。
- 这样的事情的最佳实践是什么
- 外面有这样的东西吗？我已经搜索过了，但没有成功也许我看错了方向
- 我应该坚持使用Parse SDK吗它被很好地识别和包含
我是Applicasa的开发人员福音传道者。我们为移动应用程序开发人员构建了一套很酷的工具，其中包括提供BaaS服务，该服务与Parse、StackMob和其他服务相比采用了一些不同的方法。我认为它为解决从第三方SDK API中抽象出来的问题提供了一个有用的视角，从而允许您用其他提供商或您自己的提供商替换后端。/免责声明
外面有这样的东西吗？我已经搜索过了，但没有成功，但也许我找错了方向
虽然还有其他BaaS提供商提供类似和差异化的功能，但我不知道有哪个产品以不可知的方式完全抽象了第三方提供商。
这样的事情的最佳实践是什么？
我认为你已经表现出了朝着正确的方向开始的坚实基础。
首先，您正确地预测了您最终会得到许多不同的类，这些类以后端不可知的方式封装对象和所需的功能。当然，这个数字将取决于你想要什么样的抽象和封装。你概述的方法听起来也像我开始这样一个项目的方式—为我的应用程序需要与之交互的所有对象创建类，并在这些类(或它们都扩展的基类)上实现自定义方法，这些方法将完成与后端提供者交互的实际工作。
因此，如果我正在构建一个应用程序，例如，有一个Foo、Bar和Baz对象，我会创建这些类作为我的内部API的一部分，并提供应用程序所需的所有必要功能。所有应用程序逻辑和功能操作都只与这些类交互，所有应用程序的逻辑和功能都与数据后端无关(这意味着没有内部功能可以依赖于数据后端，但对象类将提供一个一致的接口，允许执行操作，同时保持数据处理方法的私有性)。
然后，我可能会让每个类从BaseObject类继承，其中包括实际与数据后端(基于提供者或我自己的自定义远程后端)进行通信的方法。BaseObject类可能具有类似saveObject、getById:、getObjects的方法(具有一些用于执行对象过滤/搜索的适当参数)。然后，当我想在未来更换我的后端数据服务时，我只需要专注于更新处理数据交互的BaseObject类方法，而我所有的应用程序逻辑&功能与Foo、Bar和Baz类绑定，实际上并不关心获取/保存/更新/删除操作在幕后如何工作。
现在，为了让事情尽可能简单，我构建了我的BaaS模式来匹配内部对象类名(根据BaaS的要求，我可以使用isKindOfClass:或NSStringFromClass:调用)。这意味着，如果我使用Parse，我会想让我的save方法获得类名的NSStringFromClass:来执行数据操作。如果我使用像Applicasa这样的服务，它为数据交互生成本地对象的自定义SDK，我希望将自定义数据操作建立在isKindOfClass:结果的基础上。如果我想要更强的灵活性(也许是为了允许使用多个后端提供程序，或者其他一些复杂的要求)，我会让所有的子类通过某种自定义方法(如getSchemaName)告诉BaseObject数据操作要使用什么模式名称。我可能会将其定义为BaseObject方法，该方法默认情况下会将类名作为字符串返回，但随后会在子类上实现以进行进一步的自定义。因此，BaseObjectsave方法的内部可能看起来像这样：
- (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，看看你喜欢另一个提供商的程度(或者为你开发自己的数据解决方案提供一条简单的途径)。
我希望这能有所帮助。
我是StackMob的平台传道者，我想我会回答这个问题。我们使用核心数据接口构建了iOS SDK。您将使用常规的核心数据，并且我们已经覆盖了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