Android 内容提供者是存储库模式的实现吗？

由定义为设计模式，使用类似集合的接口在域和数据映射层之间进行中介，以访问域对象

基本上，它将一个或多个I/O设备（云、磁盘、数据库等）抽象为一个通用的集合，如接口，您可以在其中使用它

在上，应用程序所需的所有数据都通过存储库实现（接口位于域层）来自该层，该存储库实现使用存储库模式，该策略通过工厂根据特定条件选择不同的数据源

然而，正如内容提供商的教授所指出的

书中使用了内容提供者。这一方法最初是由以下人员提出的

因此，与其使用内容提供者，为什么不使用它作为存储库模式本身呢

---

这是一个有趣的问题。我想我的第一个答案是否定的，内容提供者不是存储库模式的实现

正如您所提到的，存储库模式旨在将业务逻辑（域）与数据层分离。这种方法允许您为业务逻辑创建单元测试（所以域根本不应该依赖于Android）。通过使用内容提供商，您需要在您的域中具有某种Android对象

您可以想象一种将内容提供者逻辑隐藏在接口后面的方法，但是您将失去内容提供者允许您做的许多好事情

如果你对Android架构感兴趣，我建议你看看这个Github项目。您将找到一种很好的方法来分离表示、域和数据层，域和数据之间的通信是通过使用存储库模式完成的

---

希望这会有帮助

内容提供者是一个

Android

组件，如果将存储库概念与此组件混合使用，气味将不好，它会对应用程序产生阻塞依赖。

将ContentProviders用作存储库的问题是，您在模型中将依赖项添加到Android框架中。使用存储库模式可以轻松地模拟、测试和替换实现

正确的方法是将ContentProvider隐藏在接口下，并让模型通过该接口访问数据。这样，您的代码就与平台解耦了

---

基本上，ContentProvider是您要抽象的I/O源。

简短回答：ContentProvider是数据源，而不是存储库

SQL数据库/Android Contentproviders/Repositories的目的是创建/读取/更新/删除/查找数据

存储库通常在高级业务特定的java类（如客户、订单、产品等）上运行 而SQL数据库和Android Contentproviders则将低级表、行和列作为数据源进行操作

因为SQL数据库不是存储库，所以Android Contentprovider也不是存储库

---

但是，您可以通过使用底层内容提供者来实现存储库，我将提到Dianne Hackborn（来自Android框架团队）来给出我的观点

内容提供者

最后，ContentProvider是一个相当专业的工具，用于将数据从应用程序发布到其他地方。人们通常认为它们是数据库上的抽象，因为对于这种常见情况，它们内置了大量API和支持。。。但从系统设计的角度来看，这不是他们的观点

这些对系统来说是一个应用程序的入口点，用于发布由URI方案标识的命名数据项。因此，应用程序可以决定如何将其包含的数据映射到URI命名空间，将这些URI分发给其他实体，这些实体反过来可以使用这些URI访问数据。在管理应用程序时，系统可以做一些特殊的事情：

•分发URI并不要求应用程序保持运行，因此这些URI可以在拥有应用程序的应用程序死机的情况下到处传播。只有当有人告诉系统，“嘿，给我这个URI的数据”时，它才需要确保拥有该数据的应用程序正在运行，这样它才能要求应用程序检索并返回数据

•这些URI还提供了一个重要的细粒度安全模型。例如，应用程序可以将其拥有的图像的URI放在剪贴板上，但将其内容提供程序锁定，这样就没有人可以自由访问它。当另一个应用程序从剪贴板中取出该URI时，系统可以给它一个临时的“URI权限授予”，这样它就可以只访问该URI后面的数据，而不访问应用程序中的其他数据

我们不关心的是：

如何实现内容提供商背后的数据管理并不重要；如果您不需要SQLite数据库中的结构化数据，请不要使用SQLite。例如，FileProvider helper类是通过内容提供商使应用程序中的原始文件可用的一种简单方法

此外，如果您没有将应用程序中的数据发布给其他人使用，则根本不需要使用内容提供商。诚然，由于围绕内容提供者构建了各种帮助程序，这是一种将数据放入SQLite数据库并使用它填充UI元素（如ListView）的简单方法。但如果这些东西让你想做的事情变得更加困难，那么请不要使用它，而是为你的应用程序使用更合适的数据模型。

全文如下:

---

这个问题值得称赞，这是一个很好的观察：）。IMHO，这不是一个肯定或否定的问题，因为这是一个相当普遍的问题，就像大多数设计模式相关的主题一样。答案取决于您考虑的环境：

如果你有一个完全依赖平台的应用程序，这意味着需要考虑acc