Android 应用程序和 (Android) 库架构
我正在设计一个 Android 应用程序，我有几个问题想听听您的意见。
现在，我想到的架构如下：
- 用于用户界面的Android应用程序、
- 用于业务逻辑的库（Android或“纯”Java？）、
- 用于访问SQLLite数据库的Android库（将由业务逻辑使用） ，
- 用于访问 Wifi/BT 模块的 Android 库（将由业务逻辑使用）。
因为很可能在不久的将来，该 Android 应用程序的基于 Java 的版本可能会针对 Win 开发/Mac/Linux，我试图将业务逻辑与 Android 特定的 API 尽可能分开。
基本上，业务逻辑需要使用嵌入式 SQLite DB 以及使用 BT 适配器并通过 Wifi 访问互联网，这可以使用两个专用的 Android 库来完成。问题是我希望业务逻辑只是一个“纯”Java 库，而不是构建在 Android 项目上。根据此架构，这是否可行，因为知道 Android 应用程序可能会有一个配置“模块”，负责在需要时设置、配置和启动两个基于 Android 的库。
您认为当前选择的架构有意义吗？
您对此应用程序的建议是什么：
- 尽可能模块化，具有良好的抽象级别（在 DB 和 BT/Wifi 适配器上），使
- 业务逻辑尽可能清晰地与 Android API 保持一致，
- 需要最少的更改来适应整个解决方案对于经典的 Java 应用程序。
预先感谢您的时间和意见。
I am working on designing an Android application, and I have several questions I would like to have your opinion on.
Right now, the architecture I am thinking of is the following:
- Android application for the User Interface,
- Library (Android or "purely" Java?) for the Business Logic,
- Android Library for accessing SQLLite Databases (will be used by the Business Logic),
- Android Library for accessing Wifi/BT modules (will be used by the Business Logic).
Since it is very likely that in a close future a Java based version of this Android application might be developed for Win/Mac/Linux, I am trying to keep the Business Logic as much apart from Android specific APIs.
Basically, the Business Logic will need to use the embedded SQLite DB as well as use the BT adapter and access the Internet through Wifi for example, this could be done using the two dedicated Android Library. The issue is that I would like the Business Logic to be only a "pure" Java library, and not built upon an Android project. Is that feasible according to this architecture, knowing that is is possible the Android Application will have a configuration "module" in charge to setup and configure and initiate if needed the two Android based libraries.
Does the currently chosen architecture make sense in your eyes ?
What could be your advice for this application to:
- Be as modular as possible with good abstraction level (on DB and BT/Wifi adapter),
- Keep the Business Logic as much as possible clear from Android APIs,
- Require minimal changes to adapt this whole solution for a classical Java application.
Thank you in advance for your time and opinions.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我曾问过一个类似的问题 - 我的目标是开发一个适用于 Android、Blackberry 和可能的 J2ME 的应用程序。我通过与核心业务逻辑分开实现特定于平台的组件（UI、数据库访问、网络访问）来做到这一点。核心 BL 被开发为通用 JAR 库，我将其分发给 Android 和 BB 应用程序。
虽然它有效，但我对这个解决方案并不是很满意。正如我在此处的答案中所解释的（甚至上面提到的第一个问题的答案），我面临着实际困难因为 BB/J2ME 没有跟上 Java 的发布。我的 Android 实现最终使用了大量“遗留”代码（例如，没有泛型）。
话虽如此，由于您的下一个目标是转向桌面而不是 BB 或 J2ME，因此您不仅可以保持 Android 和桌面 Java 应用程序之间的设计通用，而且还可以共享实现。
关于您关于抽象的问题，我建议采用基于接口的业务逻辑和数据库逻辑方法。我上面的答案第一段中的链接显示了如何实现此目的的简单示例，但我很乐意提供更多详细信息。
I had asked a similar question - I was aiming to develop an app for Android, Blackberry and possibly J2ME. I did this by implementing platform-specific components (UI, DB access, Network access) separately from core business logic. The core BL was developed as a common JAR library that I distributed to Android and BB apps.
Although it worked, I was not really satisfied with the solution. As I explained in an answer here, (and as even the answers to my first question above mentioned), I faced practical difficulties since BB/J2ME have not kept up with Java releases. My Android implementation ended up using a lot of "legacy" code (no generics, for example).
Having said that, since your next aim is to go desktop rather than BB or J2ME, you might be able to not only keep your design between your Android and desktop Java apps common, but also share the implementations.
Regarding your question about abstraction, I would suggest an Interface-based Business Logic and DB Logic approach. The link in the first para of my answer above shows a simple example of how to achieve this, but I would be glad to provide more details.