直接数据库访问和内容提供者之间如何决定？ [英] how to decide between direct database access and content provider?

问题描述

我正在撰写由业务逻辑和UI部分组成的应用程序。有大量的数据被BL和UI存储和访问/修改。在大多数情况下，存储数据的更改应立即由UI反映。

如何决定是否应该直接使用数据库访问？内容提供商？

我已经对此主题做了一些阅读（ 1 ， 2 ）和我了解这两个选项之间的区别。

请分享您对问题其他方面的想法，例如性能，代码开发难度等级和可维护性等。 p>

解决方案

在我写的应用程序中，我发现一旦你越过学习曲线，实现一个ContentProvider就可以

优点：

• 没有外部依赖关系。


• 数据库连接生命周期由ContentProvider处理。


• 轻松地在Intent中的活动之间传递内容URI。


• 通过CursorLoader简单的背景查询（或滚动您的自己）

缺点：

• 如果你没有一个很好的例子，可能会令人困惑。


• 如果你有企业Java背景，ORM可能会更加熟悉。
  

当我想知道如何实现ContentProvider时，我倾注了 Google的I / O 应用程序。在作出决定之前，我至少要花一天时间做原型设计，以便您获得权衡的第一手体验。

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.

解决方案

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.

这篇关于直接数据库访问和内容提供者之间如何决定？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！