0

我正在开发一个 Android 应用程序，将其数据存储在通常的 SQLite DB 中。我必须将这些数据公开给我的应用程序（活动和服务）的组件以及其他应用程序。

不幸的是，在将这些数据存储到数据库之前以及将它们从数据库中取出之前，我必须以各种可能复杂的方式对这些数据进行操作。我必须编辑字段，从几行或几列聚合数据等等。也就是说：我必须执行您可以看到由许多商业智能程序和许多统计数据执行的典型“数据按摩”。

这意味着单独的 SQLite DB 太少了。我要做的不仅仅是简单的 CRUD。

内容提供商似乎也不是解决方案。典型的 Android CP 实现的接口非常非常类似于标准 CRUD，更重要的是，它始终返回游标（按行和列组织的临时数据表）。对于我的需要，它看起来太像一个非常薄的 SQL 数据库包装。我仍然需要了解我是否可以将我的业务逻辑放入 CP 本身，是否可以扩展外部 CP 接口（“内容：...”）并且天气这可以被认为是一个良好实践。

也许 Android 服务可以给我一种方法来公开我的功能，我可以将 SQLite DB（或包含 SQLite DB 的 CP）嵌入到服务中。我仍然必须了解这是否可以成为解决方案以及如何解决。

我真正需要的很可能是一个 RESTful Web 服务：

  1. 存储数据的 SQL 数据库，是我的“事物”的核心
  2. 接受动词（GET、PUT、POST 等）和单/复数名称（“People”、“John Doe”等）并返回“对象”（不一定是“Java 对象”）的接口。它们可能只是JSON 或 XML 文件/流）。该界面将是从外部可见的唯一层。
  3. 中间，我的“业务逻辑”用来操作数据。

当然，标准 CP 与 RESTful WS 非常相似，很可能是我的问题的解决方案。我只是不明白一个 CP 是否足够灵活。例如，看起来 CP 只能接受类似 GET/PUT 的请求，并且除了游标之外它不能返回任何其他内容。

那么，您将使用什么来向应用程序的各个部分（活动）和其他应用程序公开非仅 CRUD 功能和非仅基本数据？

只是一个 Android 内容提供程序（也许在 CP 本身内编写您的业务逻辑）？

一个环绕 SQL DB（甚至环绕 CP）的 Android 服务？

还有什么？

哪种架构最优雅（“可维护”、“可扩展”、“灵活”、“开放”）？是否存在任何“最佳实践”？

您的考虑/建议？

4

2 回答 2

0

好的，看起来在我的案例中使用的“正确”架构是 barn.gumbl 建议的架构：

  1. 在最内层，使用 SQLite DB 来存储数据。
  2. 使用 Android 内容提供程序包装 SQLite DB。这并不是真正需要的，但它几乎总是一个好主意，因为它使代码更加模块化。您可以从应用程序的任何活动/服务以及允许这样做的任何外部应用程序访问 CP。
  3. 使用 Android 服务包装 CP。这是公开/发布与简单 CRUD 不同或更丰富的 API 的唯一方法（如我的情况）。这也是返回与游标对象不同的东西的唯一方法。

使用这种分层架构：

  1. 您可以在读取或写入时对数据执行任何类型的操作
  2. 您可以公开比 CP 允许的更丰富的 API
  3. 你可以返回任何类型的对象

所有这一切同时仍然尊重 Android 架构（如果有权限，CP 和服务都可以被其他应用程序使用）。

就我而言，我需要以一种非常奇怪的方式聚合数据并返回一个表示聚合的对象。这是仅靠 CP 无法以优雅的方式完成的事情。

于 2012-11-28T13:23:45.840 回答
0

我不确定我是否对您的问题有很好的理解，但您似乎对交换 SQLite、CP、Service 有点困惑。通常他们并肩工作。也许它可以帮助你：Google I/O 2010 - Android REST 客户端应用程序。

我的建议/假设：

->Activity,POJOs -> 服务（HadlerThread（分离线程+消息队列））-> CP

于 2012-11-27T19:50:32.993 回答