Android: Доступ к единой базе данных от нескольких операций в приложении?
У меня есть приложение типа списка ожидающих выполнения задач, которое хранит все данные примечания в sqlite3 базе данных. Для каждого действия в приложении нужен доступ к базе данных для редактирования различных частей данных в режиме реального времени.
В настоящее время у меня есть каждое действие, открытое его собственный объект DBManager (класс помощника, который я создал для управления базой данных). Это вызывает проблемы, хотя и я хотел бы немного более глобальное решение доступа, таким образом, я не должен сохранять открытие/закрытие/создание базой данных.
Я рассматриваю несколько возможностей и хотел бы услышать за и против о каждом, а также других предложениях.
Стиль Singleton. Имейте класс обертки, который возвращает ссылку на единственный менеджер базы данных так любое действие, для которого нужен он, может использовать его.
Статический менеджер. Имейте класс менеджера быть совершенно статическими участниками и иметь его, открывают базу данных по загрузке. Легкодоступный любым, которому нужен он (который является всеми).
Слияние между 1 и 2. Я мог сделать класс менеджера базы данных, который инициализирует членский одноэлементный экземпляр базы данных, и все методы манипулирования данными были статичны. Тогда мне даже не была бы нужна ссылка на одиночный элемент для доступа к базе данных. Мне нравится это решение лучше всего, укажите на оборотные стороны.
Предложения?
3 ответа
На мой взгляд, поставщик контента сложен, и если вы не делитесь действиями, которые вам не принадлежат, он вам не нужен. Поэтому я предлагаю вам сначала использовать одноэлементный класс. Затем, если у вас есть больше времени или оно вам нужно, используйте Content Provider.
Я успешно использовал синглтон в течение 6 месяцев без особых проблем. (Я был осторожен, чтобы сделать его синглтоном, но только один экземпляр, который загружает данные один раз)
Синглтон
- Преимущество: Простота реализации
- Преимущество: потому что я использовал общий Например, я мог бы реализовать кеширование легко и, следовательно, сделать приложение не нужно делать с базой данных как часто
- Недостаток: невозможно поделиться своими данными с внешними действиями
Поставщик контента
- Преимущество: вы можете поделиться своими данными с внешними действиями
- Преимущество: вы можете интегрироваться с API поиска
- Недостаток: сложно, необходимо представлять ваши данные в другом способ
- Недостаток: еще один Android API потратить время на изучение
Рекомендуемый способ сделать это на Android - использовать ContentProvider . Вашему первому поставщику контента может показаться больше проблем, чем оно того стоит, но как только вы усвоите шаблон, все будет не так уж плохо, если вы не пытаетесь сериализовать капли.
Это вызывает проблемы, хотя
Какие ... какие?
и я хотел бы немного больше решение глобального доступа, поэтому у меня нет продолжать открывать / закрывать / создавать база данных.
Открытие и закрытие базы данных SQLite обходится недорого. По возможности следует избегать статики и одиночных игр. Что заставляет вас думать, что ваше текущее решение плохое?