Большинство примеров в книгах и интернете советуют создавать CRUD-функции прямо в классе, унаследованном от SQLiteOpenHelper (у меня этот класс называтся CustomSQLiteOpenHelper), сразу после onCreate и onUpgrade. Для меня это неприемлемо - для каждой сущности (например, Emp, Dept и т.д.) я хочу создавать отдельные классы для операций с БД (например, EmpCrud, DeptCrud и т.д.) - вместо того, чтобы сваливать всё в одну немыслимую кучу внутри CustomSQLiteOpenHelper.

Каждая CRUD-функция в этих классах должна иметь доступ к базе данных, т.е. поинтер на объект класса SQLiteDatabase (через который будут вызываться rawQuery(), insert() и т.п.). Есть два варианта как этот поинтер организовать - хотелось бы услышать от знатоков любые за и против касаемо каждого.

Вариант номер 1:

Каждая Activity создаёт для себя экземпляр SQLiteDatabase и передаёт его в качестве аргумента при создании экземпляров ХххCrud классов. Например, в классе EmpActivity объявляем следующие пропертиз:



Соответственно, в EmpActivity.onStop() пишем:



Вариант номер 2:

Каждый ХххCrud класс наследуется от CustomSQLiteOpenHelper, например:



Тогда наследники будут просто иметь экземпляр SQLiteDatabase внутри себя:



Как известно, эти пропертиз - вызовы функций getWritableDatabase и getReadableDatabase, которые при первом к ним обращении создают соединение и размещают его в кеше, а затем возвращают его при последующих вызовах. Соединение должно быть закрыто в конце работы аппликации, для чего добавляем в функцию CustomSQLiteOpenHelper.close():



Затем в каждом Activity создаём экземпляр соответствующего ХххCrud класса. Например, в EmpActivity объявляем:



Недостатком варианта номер 2 видится то, что ХххCrud классы будут тяжеловесней (т.к. уинхерят все поля предка). Но зато меньше писанины (тем более что эта писанина - голимый code duplication).

99% сайтов (и 100% прочитанных мною книг) предлагают не его, а пихать всё в одну кучу внутри CustomSQLiteOpenHelper, а ХххCrud классы вообще не создавать (намного реже - метод номер 1, а метод 2 вообще можно искать со свечкой). В своей "тренировочной" аппликации я использую метод 2, но как-то странно, что "нас так мало" - возможно, я чего-то не вижу. Хотелось бы услышать мнение зубров. Лишь добавлю, что я только начал имплеметировать, и аппликацию пока не запускал, так что все приведённые примеры кода ещё не проверялись (наверняка что-то не учёл, но для иллюстрации вопроса сойдёт).

pand, Спасибо! Напоминает MyBatis, с которым мне приходилось иметь дело. В чём именно его удобство? И в чём неудобство (или потенциальные проблемы) прямого вызова функций класса SQLiteOpenHelper? Это практический вопрос, а не спор, если чё.

pand, thanx!

irbis_al, это решение всё равно бы поощряло дублирование кода - копипейст цвёл бы и пах. Я решил сделать иначе - запихал повторяющийся код в generic functions, а конкретные model-классы поставляют ему "уникальную" для них информацию, переопределяя функции extractContentValues() и populateFromCursor() интерфейса Crudable, которые все model-классы обязаны имплементировать. Это ещё не окончательный вариант, а скорее первичный набросок, который её допиливать и допиливать - можете глянуть здесь . Буду рад если опытные коллеги подправят или подкинут идей. Если довести до ума, то можно таскать за собой из проекта в проект.

Ну как же не дублирование? Посмотрите на CRUD-функции класса BaseCrud (по ссылке, что я дал). Не будь этих generic функций, их код копировался бы десятки (если не сотни) раз - заменялись бы только фрагменты, которые заполняют ContentValues и извлекают данные из курсора.

Так не только Вы! Авторы всех книг и статей по Андроиду тоже не согласны с концепцией предотвращения дублирования кода, и копипейстят так, что дым из ушей!