Android 应用程序和 (Android) 库架构

Question

我正在设计一个 Android 应用程序，我有几个问题想听听您的意见。

现在，我想到的架构如下：

• 用于用户界面的 Android 应用程序，
• 用于业务逻辑的库（Android 或“纯”Java？），
• 用于访问 SQLLite 数据库的 Android 库（将由业务逻辑使用），
• 用于访问 Wifi/BT 模块的 Android 库（将由业务逻辑使用）。

由于很可能在不久的将来会为 Win/Mac/Linux 开发基于 Java 的 Android 应用程序版本，因此我试图将业务逻辑与 Android 特定的 API 分开。

基本上，业务逻辑将需要使用嵌入式 SQLite DB 以及使用 BT 适配器并通过 Wifi 访问 Internet，例如，这可以使用两个专用的 Android 库来完成。问题是我希望业务逻辑只是一个“纯”Java 库，而不是建立在 Android 项目之上。根据这种架构是否可行，知道 Android 应用程序可能会有一个配置“模块”负责设置和配置，并在需要时启动这两个基于 Android 的库。

当前选择的架构在您眼中有意义吗？

您对这个应用程序有什么建议：

1. 尽可能模块化并具有良好的抽象级别（在 DB 和 BT/Wifi 适配器上），
2. 让业务逻辑尽可能远离 Android API，
3. 只需极少的更改即可使整个解决方案适应经典的 Java 应用程序。

提前感谢您的时间和意见。

Answer 1

我曾问过similar question - 我的目标是为 Android、Blackberry 和可能的 J2ME 开发一个应用程序。我通过与核心业务逻辑分开实现特定于平台的组件（UI、DB 访问、网络访问）来做到这一点。核心 BL 是作为通用 JAR 库开发的，我将其分发给 Android 和 BB 应用程序。

虽然它有效，但我对解决方案并不满意。正如我在answer here 中解释的那样（甚至是我上面提到的第一个问题的答案），我遇到了实际困难，因为 BB/J2ME 没有跟上 Java 的发布。我的 Android 实现最终使用了大量“遗留”代码（例如，没有泛型）。

话虽如此，由于您的下一个目标是使用桌面而不是 BB 或 J2ME，因此您可能不仅可以在 Android 和桌面 Java 应用程序之间保持设计通用，还可以共享实现。

关于您关于抽象的问题，我建议使用基于接口的业务逻辑和数据库逻辑方法。上面我的答案第一段中的链接显示了如何实现此目的的简单示例，但我很乐意提供更多详细信息。