POJO против курсоров в Android

Я столкнулся с подобными проблемами. Сейчас я отхожу от POJO. Обратите внимание, однако, что вы можете создать свой собственный Cursor интерфейс для набора POJO, если вы того пожелаете.

Мне нравится создавать классы POJO с поддержкой курсора. Класс POJO с поддержкой Cursor имеет конструктор, который принимает Cursor и обеспечивает следующие преимущества:

• Простые в использовании геттеры, которые возвращают правильный тип контента, намного лучше, чем получение индексов и необходимость запоминать тип данных в базе данных.
• Методы-получатели, которые вычисляют свои результаты из других методов-получателей, точно так же, как должно быть объектно-ориентированное программирование.
• Возвращаемые значения геттера могут быть перечислениями!

Эти несколько преимуществ стоят некоторого стандартного кода, многие ошибки были предотвращены теперь, когда инженеры-пользователи сами не обращаются к столбцам курсора. Мы по-прежнему используем класс CursorAdapter, но первой строкой в ​​методе bindView является создание POJO с поддержкой Cursor из Cursor, и с этого момента код становится красивым.

Ниже приведен пример реализации, для инженеров-пользователей несложно превратить непрозрачный курсор в четко определенный объект пользователя, с этого момента его можно передавать и получать к нему доступ, как к обычному POJO, пока поддерживающий курсор не закрыт. SmartUserCursor — это специальный класс, который я написал для обеспечения того, чтобы позиция курсора запоминалась и восстанавливалась до того, как к курсору будет осуществлен доступ, а также он сохраняет индексы столбцов курсора, чтобы поиск выполнялся быстро.

ПРИМЕР:

public class User {

    private final SmartUserCursor mCursor;

    public User(SmartUserCursor cursor, int position) {
        mCursor = new SmartUserCursor(cursor, position);
    }

    public long getUserId() {
        return mCursor.getLong(SmartUserCursor.Columns.userId);
    }

    public UserType getType() {
        return UserType.valueOf(mCursor.getString(SmartUserCursor.Columns.type));
    }

    public String getFirstName() {
        return mCursor.getString(SmartUserCursor.Columns.firstName);
    }

    public String getLastName() {
        return mCursor.getString(SmartUserCursor.Columns.lastName);
    }

    public final String getFullName() {
        return getFirstName() + " " + getLastName();
    }

    public static User newUserFromAdapter(BaseAdapter adapter, int position) {
        return new User((SmartUserCursor)adapter.getItem(position), position);
    }

    public static User newUserBlocking(Context context, long UserId) {
        Cursor cursor = context.getContentResolver().query(
                Users.CONTENT_URI_CLIENT,
                Users.DEFAULT_USER_PROJECTION,
                Users.Columns.USER_ID+"=?",
                new String[] {String.valueOf(UserId)},
                null
        );

        if (cursor == null || !cursor.moveToFirst()) {
            throw new RuntimeException("No User with id " + UserId + " exists");
        }

        return new User(new SmartUserCursor(cursor, Users.DEFAULT_USER_PROJECTION), -1);
    }

    public final void closeBackingCursor() {
        mCursor.close();
    }

}

Один голос за объекты сущностей (POJO). Передача курсоров, особенно на слой пользовательского интерфейса, кажется мне такой неправильной (независимо от того, подразумевает ли это Android SDK). Обычно есть несколько способов заполнить ваш пользовательский интерфейс, и я стараюсь избегать тех, которые напрямую используют курсоры. Например, чтобы заполнить свои пользовательские представления списка, я использую SimpleAdapter и даю объектам своей коллекции возможность возвращать представление себя как List<? extends Map<String, ?>> для конструктора SimpleAdapter.

Я использую шаблон, в котором каждая таблица обернута объектом сущности и имеет класс поставщика, который обрабатывает мои операции CRUD, связанные с этой сущностью. При желании, если мне нужны расширенные функциональные возможности для коллекций, я также их оборачиваю (т.е. EntityItems extends ArrayList<EntityItem>). У провайдера есть базовый класс, который я передаю ссылку классу DbAdapter, который выполняет тяжелую работу вокруг базы данных.

Основная причина, помимо личных предпочтений, заключается в том, что я хочу скрыть этот код как можно дальше от своего пользовательского интерфейса:

String something = cursor.getString(cursor.getColumnIndex(COLUMN_NAME_CONSTANT));

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

Ответы 4-летней давности. Я думаю, что теперь у нас достаточно мощности процессора, чтобы справиться с большим количеством задач. Моя идея заключалась бы в том, чтобы работать только с POJO и ArrayList; и расширение CursorLoader для сопоставления курсора с POJO в фоновом режиме и доставки массива в активность;

если вы не запрашиваете сотни строк, но тогда, как часто вы это делаете по сравнению с удобством использования POJO, геттеров и сеттеров