Пишем свой Orm под Android с канастой и сеньоритами

Вступление

Идея написать свое приложение под Android пришла мне на пятый день отдыха в солнечном Таиланде. Не буду вдаваться в подробности что именно натолкнуло меня на неё, как и что я задумал за приложение (просто статья не об этом). Однако идея крепко укоренилась и на шестой день пребывания, воспользовавшись бесплатным интернетом в отеле, на ноутбук, взятый только ради просмотра фильмов и скидывания фотографий с фотоаппарата, я закачал MySql.
Начал я, как вы наверное уже догадались, с реляционный модели.
Работа шла трудно, но через пару месяцев с моделью я закончил и окунулся в дебри разработки под Android. До этого, под мобильные платформы я писал только на .Net Compact Framework, но так как с Java был знаком не понаслышке, накидать простенькую форму с кнопками труда не составило. Объектная модель, ожидаемо, трудностей не вызвала вообще и я, радостно предвкушая как сейчас мои тестовые данные улетят куда-то в недра устройства, открыл раздел Data Storage ^[1] на сайте Android Developers ^[2]. Раздел Using Databases ^[3] нельзя назвать исчерпывающим, однако все необходимы ссылки на API он содержит, и я принялся писать своего наследника от SQLiteOpenHelper ^[4]. После пары удачных проб, разбалованный Entity Framework’ом, я понял, что и тут бы было неплохо использовать какой-нибудь orm, так как сущностей у меня набралось больше десятка. Вбив в Великом и Ужасном ^[5] «android orm», первую же ссылку я получил на эту ^[6] статью, и несколько полезных на StackOverflow. Набрав в общей сложности три orm’а, я приступил к экспериментам.

Эксперименты

Первым подопытным стало конечно OrmLite.

OrmLite ^[7]

В принципе неплохая реализация, использование аннотации. Еще мне понравилась реализация onCreate и onUpgrade в DatabaseHelper и она запомнилась где-то в глубинах моей памяти. Но! Создавать для каждой сущности еще и дополнительный класс <%EntityName%>DAO – увольте! Можно кончено попытаться сделать один, прицепляемый к базовому классу сущностей, но проблем от этого будет только больше.

GreenDAO ^[8]

Дальше заголовка «Data model and code generation» в документации я читать не стал. Может быть конечно такой подход мне не совсем понятен и в нем есть свои плюсы, но, привыкнув к атрибутам, использовать аннотации мне нравиться больше.

ActiveAndroid ^[9]

На данный orm я возлагал большие надежды: аннотации, создание базы с использование manifest’а (запомнилось в тех же глубинах что и Helper OrmLite), маппинг через методы самой сущности… В общем вроде всем данный framework хорош, но потянуть мою реляционную модель он не смог.

Реляционная модель

Немного отступлю от orm, чтобы наконец объяснить, что за реляционная модель у меня получилась. В принципе, все в ней конечно стандартно, за исключением одной вещи. В Entity Framework’е, при маппинги наследуемых сущностей создается одна таблица с избытком полей. Например: предположим у нас есть сущность «Машина»

/**
 * Машина
 */
public class Car {

    /**
     * Тип
     */
    private CarType type;
    
    /**
     * Мощность двигшателя
     */
    private int enginePower;

    /**
     * Кол-во дверей
     */
    private int doorsCount;
}

И наследуемая от неё сущность «Грузовик»

/**
*Грузовик
*/
public class Truck extends Car{

    /**
     *Указвает на то, что это самосвал.
     */
    private boolean isTipper;
}

Обычно orm должен сгенерировать такой запрос на создание таблицы:

CREATE TABLE car (id INTEGER PRIMARY KEY, type INTEGER REFERENCE car_type(id), engine_power INTEGER, doors_count INTEGER, is_tipper INTEGER);

Я же, в свое время впечатленный наследованием таблиц в PostgreSQL, сделал такую модель:

CREATE TABLE car (id INTEGER PRIMARY KEY, type INTEGER REFERENCES car_type(id), engine_power INTEGER, doors_count INTEGER);
CREATE TABLE truck (id INTEGER REFERENCES car(id) ON DELETE CASCADE,  is_tipper INTEGER);

Сразу уточню, что это только пример, и в моих сущностях, полей и связей намного больше, а посему забивать таблицу Car, тем, что к ней не относиться – я не хотел.
В результате выборку надо делать через Left Join.
В результате, я решил изобрести велосипед, сиречь написать свой собственный Orm.

Концепция

1. Никаких генераторов сущностей! Все через аннотации.
2. Как можно меньше разных типов аннотаций, в идеале две (пока удается этому придерживаться).
3. Запрос сущностей через статические методы самого класса.
4. Создание, сохранение и удаление – через методы экземпляров.
5. Максимально простой Helper с возможностью создания начальных записей таблиц.

Реализация

Аннотации

Аннотация у меня всего две:

1. Table – применяется к классу, описывает таблицу. Свойства:
   • Name – имя таблицы, если пустое – то берется имя класса в нижнем регистре.
   • CashedList – указывает, надо ли для экземпляров данного класса загружать каждый заново, или искать его в закешированном списке (объясню чуть позже).
   • LeftJoinTo – указывает класс к которому данный является наследником.
   • RightJoinTo – указывает классы, которые расширяют текущий.
2. Column – применяется к полю, описывает столбцы таблицы. Свойства:
   • Name – имя столбца, если пустое – то берется имя поля в нижнем регистре.
   • PrimaryKey – указывает что данное поле ключевое.
   • Inherited – указывает, что данная аннотация наследуется.
   • ReferenceActions – список действий для References поля.

Сущности

Опять же будем рассматривать их из примера:

public class BaseEntity extends OrmEntity {

	@Column(primaryKey = true, inherited = true)
	private Long id;
}

@Table(name = “car_type”, cashedList = true)
public class CarType extends BaseEntity  {

	@Column
	private String code;
}

@Table(rightJoinTo = {Truck.class})
public class Car extends BaseEntity {

	@Column(name = “car_type”)
	private CarType type;

	@Column
	private List<Wheel> wheels;

	@Column(name = “engine_power”)
private int enginePower;

@Column(name = “doors_count”)
private int doorsCount;
}

@Table
public class Wheel extends BaseEntity {

	@Column(name = “car_id”)
	private Car car;

	@Column
	private String manufacturer;
}

@Table(leftJoinTo = Car.class)
public class Truck extends Car {

	@Column(name = “is_tipper”)
	private boolean isTipper;
}

В результате работы Helper’а похожего на Helper OrmLite получим следующие запросы:

CREATE TABLE car_type (id INTEGER PRIMARY KEY, code TEXT);
CREATE TABLE car (id INTEGER PRIMARY KEY, car_type REFERENCES car_type (id), engine_power INTEGER, doors_count INTEGER);
CREATE TABLE wheel (id INTEGER PRIMARY KEY, car_id INTEGER REFERENCES car (id), manufacturer TEXT);
CREATE TABLE truck (car_id REFERENCES car (id), is_tipper INTEGER);

Дополнительно по orm

Класс OrmEntity имеет защищенный статический метод:

protected <T extends OrmEntity> List<T> getAllEntities (Class<T> entityClass)

Например, в классе CarType реализуем такой метод:

public List<CarType> getAllEntities() {
	return getAllEntities(CarTpe.class);
}

Так же в OrmEntity есть защищенные методы alter и delete. В базовом классе BaseEntity я прячу alter, и дергаю его через insert и update, ну так, чисто для красоты.

Проверки и ограничения

У сущности обязано быть поле помеченное primaryKey. Оно должно быть обязательно типа Long (именно Long, что бы изначально id было null’ом и alter смог понять, что это, insert или update).
Если поле помеченное Column имеет тип List с классом сущностей унаследованных от OrmEntity, то в этом классе обязательно должно быть поле типа первого класса помеченное Column.
Если поле помеченное Column имеет тип унаследованный от OrmEntity, то у этого типа обязано быть поле помеченное Column с primaryKey.
Если класс помечен Table с leftJoinTo, то у класс указанный в leftJoinTo, должен быть помечен Table в rightJoinTo которого добавлен первый класс.
Все не пройденные проверки бросают Exception.

Заключение

В текущей момент orm еще не закончен, и я развиваю его по мере моих надобностей. Сейчас поддерживаются типы int, Long, double, String, Drawable. На подходе Document.
Из действия по references пока есть только ON DELETE по нему можно сделать и CASCADE и SET NULL и остальные.
LeftJoinTo – пока работает не полностью, сейчас доделываю как раз его.
Как только доделаю все задуманное и причешу код – выложу библиотеку на GitHub.

Автор: Scogun

Источник ^[10]