POJO в сравнении с курсорами в Android
Обычно я обычно определяю уровень модели своих приложений с помощью POJO, таких как Article, Comment и т. Д.
Я собирался реализовать AlphabetIndexer в адаптере одного из моих ListViews. Прямо сейчас этот адаптер принимает коллекцию статей, которую я обычно получаю из своей оболочки вокруг SQLiteDatabase.
Сигнатура конструктора AlphabetIndexer выглядит следующим образом:
public AlphabetIndexer (Cursor cursor, int sortedColumnIndex, CharSequence alphabet)
Поскольку он не принимает Collection или что-то подобное, только Cursor, это заставило меня задуматься: может быть, мне не следует создавать объекты для моей модели, и просто использовать курсоры, возвращенные из базы данных?
Итак, вопрос , я думаю: что мне делать, представлять данные с помощью Коллекций POJO или просто работать с Курсорами во всем моем приложении?
Любой ввод?
2 ответа
У меня возникали похожие проблемы. Прямо сейчас я стараюсь держаться подальше от POJO. Однако обратите внимание, что вы можете создать свой собственный интерфейс Cursor для коллекции POJO, если захотите.
Один голос за объекты сущностей (POJOs). Передача курсоров, особенно на уровень пользовательского интерфейса, кажется мне очень неправильной (независимо от того, подразумевает ли Android sdk это или нет). Обычно существует несколько способов заполнения пользовательского интерфейса, и я стараюсь избегать тех, которые непосредственно используют курсоры. Например, чтобы заполнить пользовательские представления списка, я использую SimpleAdapter и предоставляю объектам коллекции возможность возвращать представление самих себя, поскольку List> для конструктора SimpleAdapter.
Я использую шаблон, в котором каждая таблица обернута объектом сущности и имеет класс поставщика, который обрабатывает мои операции CRUD, связанные с этой сущностью. Опционально, если мне нужна расширенная функциональность для коллекций, я их тоже упаковываю (т.е. EntityItems расширяет ArrayList) У поставщика есть базовый класс, в который я передаю ссылку на класс DbAdapter, который выполняет тяжелую работу вокруг базы данных.
Самая большая причина, помимо личных предпочтений, заключается в том, что я хочу скрыть этот тип кода как можно дальше от моего пользовательского интерфейса:
String something = cursor.getString(cursor.getColumnIndex(COLUMN_NAME_CONSTANT));
Если я вижу такой код в строке пользовательского интерфейса, я обычно ожидаю увидеть гораздо худшее, скрывающиеся за углом. Может быть, я просто провел слишком много времени в корпоративном мире, работая в больших командах, но я предпочитаю читабельность, если нет законной проблемы с производительностью или если это достаточно маленькая задача, где выразительность - это просто чрезмерный излишество.