Вступление
Идея написать свое приложение под Android пришла мне на пятый день отдыха в солнечном Таиланде. Не буду вдаваться в подробности что именно натолкнуло меня на неё, как и что я задумал за приложение (просто статья не об этом). Однако идея крепко укоренилась и на шестой день пребывания, воспользовавшись бесплатным интернетом в отеле, на ноутбук, взятый только ради просмотра фильмов и скидывания фотографий с фотоаппарата, я закачал MySql.
Начал я, как вы наверное уже догадались, с реляционный модели.
Работа шла трудно, но через пару месяцев с моделью я закончил и окунулся в дебри разработки под Android. До этого, под мобильные платформы я писал только на .Net Compact Framework, но так как с Java был знаком не понаслышке, накидать простенькую форму с кнопками труда не составило. Объектная модель, ожидаемо, трудностей не вызвала вообще и я, радостно предвкушая как сейчас мои тестовые данные улетят куда-то в недра устройства, открыл раздел Data Storage на сайте Android Developers. Раздел Using Databases нельзя назвать исчерпывающим, однако все необходимы ссылки на API он содержит, и я принялся писать своего наследника от SQLiteOpenHelper. После пары удачных проб, разбалованный Entity Framework’ом, я понял, что и тут бы было неплохо использовать какой-нибудь orm, так как сущностей у меня набралось больше десятка. Вбив в Великом и Ужасном «android orm», первую же ссылку я получил на эту статью, и несколько полезных на StackOverflow. Набрав в общей сложности три orm’а, я приступил к экспериментам.
Эксперименты
Первым подопытным стало конечно OrmLite.
OrmLite
В принципе неплохая реализация, использование аннотации. Еще мне понравилась реализация onCreate и onUpgrade в DatabaseHelper и она запомнилась где-то в глубинах моей памяти. Но! Создавать для каждой сущности еще и дополнительный класс <%EntityName%>DAO – увольте! Можно кончено попытаться сделать один, прицепляемый к базовому классу сущностей, но проблем от этого будет только больше.
GreenDAO
Дальше заголовка «Data model and code generation» в документации я читать не стал. Может быть конечно такой подход мне не совсем понятен и в нем есть свои плюсы, но, привыкнув к атрибутам, использовать аннотации мне нравиться больше.
ActiveAndroid
На данный 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.
Концепция
- Никаких генераторов сущностей! Все через аннотации.
- Как можно меньше разных типов аннотаций, в идеале две (пока удается этому придерживаться).
- Запрос сущностей через статические методы самого класса.
- Создание, сохранение и удаление – через методы экземпляров.
- Максимально простой Helper с возможностью создания начальных записей таблиц.
Реализация
Аннотации
Аннотация у меня всего две:
- Table – применяется к классу, описывает таблицу. Свойства:
- Name – имя таблицы, если пустое – то берется имя класса в нижнем регистре.
- CashedList – указывает, надо ли для экземпляров данного класса загружать каждый заново, или искать его в закешированном списке (объясню чуть позже).
- LeftJoinTo – указывает класс к которому данный является наследником.
- RightJoinTo – указывает классы, которые расширяют текущий.
- 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
