Блог

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

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

Большинство примеров ContentProviders, которые я нахожу, показывают, что они обращаются к базе данных напрямую. Неправильно ли располагать объект Service или Application между ContentProviders и database?

Например, я пытаюсь создать приложение для личных финансов / бюджета (например, Mint / Quicken и т.д.). У меня будет база данных транзакций и соответствующий TransactionProvider. В большинстве случаев транзакции независимы друг от друга. Тем не менее, если две транзакции помечены как часть одной и той же «Передачи», там будут некоторые поля, которые я захочу синхронизировать между двумя транзакциями. Если кто-то изменяет категорию или сумму одной транзакции, я хочу убедиться, что те же значения обновляются для транзакции для другой учетной записи передачи.

ContentProvider Может выполнять произвольный код на своих insert() , update() delete() и query() методах. Они не обязательно сопоставляются один к одному с соответствующими операциями базы данных, как и сами определения структуры (т. Е. Полей). Вы могли бы, например:

• Обновляйте более одной таблицы при вставке, обновлении или удалении.
• Сохраняйте нормализованные таблицы в SQLite, но представляйте ненормализованный интерфейс для выполнения запросов.
• Вообще не хранить данные в базе данных (например, для предоставления доступа к файлам, доступным в личном хранилище вашего приложения, или манипулирования ими).
• и c.

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

Просто для пояснения, поскольку вы начинаете разработку Android, нет необходимости создавать ContentProvider, если вы просто хотите хранить данные в SQLite — вы можете использовать SQLiteDatabase непосредственно для этого. ContentProvider, как правило, предназначен для предоставления ваших собственных данных другим приложениям или для специализированных случаев, таких как предложения по поиску.

Из Создания поставщика контента:

Решите, нужен ли вам поставщик контента. Вам необходимо создать поставщика контента, если вы хотите предоставить одну или несколько из следующих функций:

• Вы хотите предоставлять сложные данные или файлы другим приложениям.
• Вы хотите разрешить пользователям копировать сложные данные из вашего приложения в другие приложения.
• Вы хотите предоставить пользовательские предложения для поиска с использованием search framework.

Вам не нужен поставщик для использования базы данных SQLite, если она используется исключительно в вашем собственном приложении.

Если вы создаете приложение для обработки финансовых данных, оно вам, вероятно, не нужно. Вы хотите, чтобы другие приложения могли получать доступ к этим данным?