Как выбрать прямой доступ к базе данных и контент-провайдеру? - PullRequest
16 голосов
/ 11 августа 2011

Я пишу приложение, которое состоит из бизнес-логики и частей пользовательского интерфейса. Существует довольно большой объем данных, которые будут храниться и доступны / изменены как BL, так и пользовательским интерфейсом. В большинстве случаев изменения хранимых данных должны немедленно отражаться в интерфейсе пользователя.

Как мне решить, должен ли я использовать прямой доступ к БД или нет? поставщик услуг?

Я немного прочел эту тему ( 1 , 2 ) и понимаю разницу между этими двумя вариантами.

Пожалуйста, поделитесь своими мыслями о других аспектах проблемы, таких как производительность, уровень сложности разработки и сопровождения кода и т. Д.

Ответы [ 3 ]

18 голосов
/ 11 августа 2011

В приложениях, которые я написал, я обнаружил, что как только вы пройдете кривую обучения, реализовать ContentProvider довольно легко.

За

  • Нет внешних зависимостей.
  • Жизненный цикл соединения с БД обрабатывается ContentProvider.
  • Простая передача URI содержимого между операциями в намерении.
  • Простые фоновые запросы через CursorLoader (или сверните свои собственные).

Минусы

  • Может сбивать с толку, если у вас нет хорошего примера.
  • Если у вас есть корпоративный Java-фон, ORM может быть более знакомым.

Когда я пытался выяснить, как реализовать ContentProvider, я вылил пример кода в приложении ввода-вывода Google . Прежде чем вы примете решение, я бы хотя бы потратил день на его создание, чтобы вы могли получить непосредственный опыт компромиссов.

17 голосов
/ 11 августа 2011

Я бы порекомендовал потратить это дополнительное время и силы на написание вашего ContentProvider.ContentProviders - это не просто доступ к данным.Преимущества

  • У вас есть способы прослушивания ваших данных через ContentObservers
  • Контент-провайдеры сами по себе не являются поточно-ориентированными, но их легко реализовать поточно-безопасными
  • Курсорам можно предлагать обновляться с помощью notifyChange
  • ContentProvider. Вы можете добавить хорошую абстракцию, не затрагивая бизнес-уровень.Вот пример: вы используете контакты Android в вашем приложении.Завтра вы планируете ввести свои собственные контакты (через собственный веб-сервис).Контент-провайдер может быть изменен, чтобы выполнить это требование в очень изящной манере.
  • Таблицы JOIN могут очень хорошо отображаться при хорошем дизайне, не загромождая ваш код бизнес-логики.Проверьте некоторые из Android ContentProvider, такие как MediaStore или ContactsContract.Ознакомьтесь с их определениями CONTENT_URI

В общем, ContentProvider - это очень красивая концепция Android, которую стоит реализовать.И как только вы определите свои определения, добавить поддержку для большего количества данных не составит труда.Тогда это будет так же просто, как написание кода вашей базы данных в классе Helper или ваших классах бизнес-логики.

** EDIT ** Вот утилита, которая генерирует код поставщика контента из классов моделей: https://code.google.com/p/mdsd-android-content-provider/

9 голосов
/ 11 августа 2011

IMO: Single APK == прямой доступ через постоянный слой.Несколько APK (либо ваши собственные, либо желающие предоставить доступ к данным другим приложениям) == Поставщик контента по простой необходимости.

...