问题
I am writing an application that consists of business logic and UI parts. There is quite big amount of data to be stored and accessed/modified by both BL and UI. In most of the cases changes to the stored data should be reflected by UI immediately.
How do I decide whether I should or should not use direct DB access? content provider?
I have done some reading on the subject (1, 2) and I understand the difference between these two options.
Please share your thoughts on other aspects of the problem, such as performance, difficulty level of code development and maintainability, etc.
回答1:
In the apps that I've written, I've found that once you get past the learning curve, implementing a ContentProvider is pretty easy.
Pros:
- No external dependencies.
- DB connection lifecycle is handled by the ContentProvider.
- Easily pass content URIs between Activities in an Intent.
- Simple background queries via CursorLoader (or roll your own).
Cons:
- Can be confusing if you don't have a good example handy.
- If you have an enterprise Java background, ORM might be more familiar.
When I was trying to figure out how to implement a ContentProvider, I poured over the example code in Google's I/O application. Before you make a decision, I would at least spend a day prototyping one so you can get first-hand experience of the tradeoffs.
回答2:
I would recommend spending that extra time and energy to write your ContentProvider. ContentProviders are not just about sharing access to data. The advantages
- You have ways of listening to your data via
ContentObservers - ContentProviders by themselves are not thread-safe, but it is easy to implement thread-safetly
- Cursors can be asked to keep themselves up-to-date via the ContentProvider's
notifyChange - You can add good abstraction without affecting your business layer. Here's an example: You use the Android contacts in your application. Tomorrow you plan on introducing your own contacts (via your own WebService). The ContentProvider can be modified to assimilate this requirement in a very graceful manner.
- JOIN tables can be exposed very well by a nice design without cluttering your business-logic code. Check out some of the Android ContentProvider like the MediaStore or the ContactsContract. Check out their CONTENT_URI definitions
All in all, a ContentProvider is a very beautiful Android concept which is well-worth implementing. And once you have your definitions in place, it is not very difficult to add support for more data. It will then be as easy as writing your database code in a Helper class or your business-logic classes.
** EDIT ** Here's a utility which generates content provider code from model classes: https://code.google.com/p/mdsd-android-content-provider/
回答3:
IMO: Single APK == direct access through a persistence layer. Multple APKs (either your own or wanting to provide access to the data to others' apps) == Content Provider by simple necessity.
来源：https://stackoverflow.com/questions/7027647/how-to-decide-between-direct-database-access-and-content-provider