应用程序的Andr​​oid和其他平台之间的逻辑code重用：要的ContentProvider或不ContentProvider的？ [英] Logic code reuse between apps for Android and other platforms: To ContentProvider or not to ContentProvider?

问题描述

我正在开发一个应用程序，我想打都可用，Android和黑莓（可能的JavaME将来）。业务逻辑将是通用于所有平台 - 因此，因此将相应的层中code

不过，我也有一个数据层 - 这显然是不同的不同的平台。我的方法，这是有一个bean和一个抽象的数据存储类。如果我使用Android的记事本的样品，它是这样的：

注意豆：的

 公共类注{
    专用长ID;
    私人字符串名称;
    私人字符串注意事项;
    私人长期创建的;
    专用长修改;

    //适当的构造
    // getter和setter
}
 

数据存储接口：的

 公共接口NoteDataStore {
    公共布尔deleteNote（长noteId）;
    公共布尔addNote（注注）;
    公开名单＆LT;注意＆GT; listNotes（）;
    公共布尔editNote（长NoteID，接下来注意注意）;
    公开名单＆LT;注意＆GT;搜索（字符串searchString）;
}
 

每个平台将实现对数据存储接口，并进行持续的数据访问适当的。的机器人实现中，例如，将使用SQLite类用于此目的。

此方式，上级层将所有的平台之间共同 - 只要它们不使用任何特定平台的特征

。

问：的

不会对数据存储的上述（部分）与该的ContentProvider Android中重叠的功能？我想各种办法，使这个干净的，但我不相信任何人：

• 有我的ContentProvider 还实现了数据存储接口。 但是，没有这个混乱的ContentProvider的，更何况混淆的责任？

• 实施中的的ContentProvider SQLite的访问 - 然后让数据存储实现呼的ContentProvider的被窝里。 但是，这个附加层的开销？另外，我仍然需要直接使用ContentProvider的，例如使用Android的搜索框架。是不是像重复相同的功能多层？

• 上述办法逆 - 即实现在数据存储层的SQLite的;再有在幕后的的ContentProvider 调用它。我想不出如何，这是任何不同于previous方法。

底线是 - 如果不是因为的ContentProvider - 仅仅是数据存储层将正常工作和这样的设计将使跨平台的业务逻辑重用。我不能完全抛弃ContentProviders的唯一原因是Android系统的某些组件希望你公开数据作为一个的ContentProvider（搜索，例如）。

我会AP preciate你是如何在你的应用程序处理这个任何提示。先谢谢了。

修改

没有多少反应为止。任何提示都在不同平台之间code重用？也许，我需要重新句话我的问题？ （对不起 - 我是新的所以不知道该协议是什么提醒。）

。

解决方案

  

业务逻辑将是通用于所有平台 - 因此，因此将相应的层中code

。

你的code中的绝大多数会成为Android和你的其他版本之间的不同。黑莓和J2ME分享几十个教学班，Android的，主要是在 java.io 和 java.util中的。即使你的商业逻辑，将三个类库的交集外需类，最有可能的。

因此​​，我不会担心1舔约试图有一个共同的code基地。常见的设计，确保万无一失。可互换的数据模型，确保万无一失。实际面值code，不值得担心，恕我直言。

  

请问以上（部分）与该ContentProvider的Andr​​oid中的重复数据存储的不是功能？

这些API重叠行动条款。这就是它。

  

我不能完全抛弃ContentProviders的唯一原因是Android系统的某些部件希望你公开数据作为一个的ContentProvider（搜索，例如）。

没错，但在这种情况下，Android系统将不会支持你的数据模型，反正。搜索，例如，需要一个相当具体的的ContentProvider 的实施，不是任何旧的。

I'm developing an app which I want to make available both for Android and Blackberry (possibly to JavaME in the future). The business logic will be common to all the platforms - and hence, so will the corresponding layer in code.

But I also have a data layer - which will obviously be different to the various platforms. My approach to this is to have a bean and an abstract DataStore class. If I were using Android's NotePad sample, it would look like this:

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 Interface:

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);
}

Every platform would implement the datastore interface and perform the persistent data access as appropriate. The Android implementation, for example, would use SQLite classes for this purpose.

This way, the higher level "layers" would be common between all the platforms - as long as they do not use any platform-specific features.

Question:

Doesn't the functionality of the DataStore above (partially) overlap with that of the ContentProvider in Android? I thought of various approaches to make this "cleaner" but I'm not convinced with any of them:

• Have my ContentProvider also implement the DataStore interface. But, doesn't this clutter the ContentProvider, not to mention "mix up" the responsibilities?

• Implement SQLite access in the ContentProvider - and then have the DataStore implementation "call" the ContentProvider under the covers. But, what about the overhead of an additional layer? Plus, I would still need to use the ContentProvider directly, for example to use the Android Search Framework. Isn't that like duplicating the same functionality in multiple layers?

• Inverse of the above approach - i.e, implement the SQLite in the DataStore layer; and then have the ContentProvider call to it under the covers. I cannot think of how this is any different from the previous approach.

Bottom line is - if it wasn't for ContentProvider - just the DataStore layer would work fine and this design would make the business logic reusable across platforms. The only reason I cannot entirely discard the ContentProviders is certain components of the Android system expect you to expose data as a ContentProvider (Search, for example).

I would appreciate any tips on how you have handled this in your apps. Thanks in advance.

EDIT:

Not many responses so far. Any tips at all on code reuse between various platforms? Or perhaps, I need to re-phrase my question? (I'm sorry - I'm new at SO. Not sure what the protocol is for "reminders").

解决方案

The business logic will be common to all the platforms - and hence, so will the corresponding layer in code.

The vast majority of your code will be different between Android and your other versions. Blackberry and J2ME share a few dozen classes with Android, mostly in java.io and java.util. Even your "business logic" will need classes outside of the intersection of the three class libraries, most likely.

Hence, I wouldn't worry one lick about trying to have a common code base. Common design, sure. Interchangeable data models, sure. Actual literal code, not worth worrying about, IMHO.

Doesn't the functionality of the DataStore above (partially) overlap with that of the ContentProvider in Android?

The APIs overlap in terms of actions. That's about it.

The only reason I cannot entirely discard the ContentProviders is certain components of the Android system expect you to expose data as a ContentProvider (Search, for example).

True, but in those cases, "the Android system" will not be supporting your data model, anyway. Search, for example, requires a fairly specific ContentProvider implementation, not just any old one.

这篇关于应用程序的Andr​​oid和其他平台之间的逻辑code重用：要的ContentProvider或不ContentProvider的？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！