在Android和其他平台之间实现逻辑代码重用：使用ContentProvider还是不使用？

Question

我正在开发一款应用程序，希望能够在Android和Blackberry上使用（未来可能还会加入JavaME）。所有平台的业务逻辑都将是通用的，因此代码中对应的层也将是通用的。

但我还有一个数据层——显然这将因不同平台而异。我的解决方案是使用一个bean和一个抽象的DataStore类。如果我使用Android的NotePad示例，它将如下所示： Note Bean：

public class Note {
    private long id;
    private String title;
    private String note;
    private long created;
    private long modified;

    //Appropriate constructors
    //Getters and Setters
}

DataStore接口：

public interface NoteDataStore {
    public boolean deleteNote(long noteId);
    public boolean addNote(Note note);
    public List<Note> listNotes();
    public boolean editNote(long noteId, Note note);
    public List<Note> search(String searchString);
}

每个平台都会实现数据存储接口并根据需要执行持久化数据访问。例如，Android实现将使用SQLite类来实现此目的。

这样，高级别的“层”将在所有平台之间共用 - 只要它们不使用任何特定于平台的功能。

问题：DataStore的功能是否与Android中的ContentProvider部分重叠？我考虑了各种方法来使其更加“清晰”，但我对其中任何一种都不太满意：

1. 让我的ContentProvider也实现DataStore接口。但是，这不会让ContentProvider变得混乱，更不用说“混淆”责任了吗？

2. 在ContentProvider中实现SQLite访问，然后使DataStore实现“调用”ContentProvider。但是，这会增加额外的开销。此外，我仍然需要直接使用ContentProvider，例如使用Android Search Framework。这不是在多个层中复制相同的功能吗？

3. 与上述方法相反 - 即在DataStore层中实现SQLite；然后让ContentProvider在幕后调用它。我想不出这与前一种方法有何区别。

总之，如果没有ContentProvider - 只有DataStore层将正常工作，并且此设计将使业务逻辑在各个平台上可重用。唯一的原因是我无法完全放弃ContentProviders是Android系统的某些组件希望您将数据公开为ContentProvider（例如搜索）。

我会感激任何有关如何在您的应用程序中处理此问题的提示。谢谢提前。

- curioustechizen

Answer 1

这个问题现在已经超出了ContentProvider的范围，进入了更一般的领域。我已经使用原始问题中的第二个要点实现了我所发布的内容 - 也就是，在ContentProvider中实现SQLite访问，然后使DataStore实现在幕后“调用”ContentProvider。

但是，在我继续进行的过程中，我看到更多类似的挑战，试图保持代码的共同性。以下是一些示例：

1. Blackberry和JavaME平台上不支持java.util.List。唯一的解决方法是使用数组或Vectors。在Android中使用Vector会有多大影响？

2. 将POJO绑定到XML/JSON的库在JavaME/BB平台上效果不佳。其中一些库使用反射（GSON），而大多数库使用注释，或至少使用java.util.List。这些都在JavaME上不可用。 因此，在这些平台上最好手动编写XML/JSON解析/框架逻辑。这引出了一个问题-一旦付出了编写这样的解析器的努力，为什么不在Android上重复使用呢？

3. JavaME/BB不支持泛型。虽然这并不是什么大问题（因为我的所有代码都是内部的-不是API），但我要么会在Eclipse中看到太多警告，要么在我的代码中有太多的@SuppressWarnings("rawtypes")！

嗯，看来我想要实现的东西并不像我想象的那么简单！

- curioustechizen

Answer 2

业务逻辑将对所有平台通用，因此代码中的相应层也将如此。在Android和其他版本之间，您的大部分代码将不同。Blackberry和J2ME与Android共享几十个类，主要位于java.io和java.util中。即使是您的“业务逻辑”，也需要超出三个类库交集之外的类，最有可能是这样。因此，我不会担心尝试拥有一个共同的代码库。共同设计，当然可以。可互换的数据模型，当然可以。实际的文字代码，不值得担心，我的意见是。API在操作方面重叠。仅此而已。唯一的原因是我不能完全放弃ContentProviders是因为Android系统的某些组件希望您将数据公开为ContentProvider（例如搜索）。但在这些情况下，“Android系统”将无论如何都不支持您的数据模型。例如，搜索需要一个相当特定的ContentProvider实现，而不仅仅是任何旧的ContentProvider。

- CommonsWare

---

我认为实际代码重用的程度取决于业务逻辑。我曾经开发过一个联系人同步应用程序，它有Android、BB和JavaME版本。UI、联系人访问和HTTP层对每个平台都是特定的，但核心同步层在代码中是通用的（作为JAR库分布到所有3个版本）。这个同步层绝对是应用程序的“主体”（从设计工作和代码方面来看）。我的观点是 - 在某些情况下，业务逻辑使得代码重用不仅可能，而且也是有利的。 - curioustechizen