Как выбирать между прямым доступом к базе данных и поставщиком контента?

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

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

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

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

Ответы

Ответ 1

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

Pros

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

против

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

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

Ответ 2

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

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

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

** РЕДАКТИРОВАТЬ ** Здесь утилита, которая генерирует код поставщика контента из классов модели: https://code.google.com/p/mdsd-android-content-provider/

Ответ 3

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