What is orm android

5 лучших ORM для Android

Как вы понимаете, мы имеем самое непосредственное отношение к разработке приложений для Android, ведь именно эта ОС установлена на YotaPhone. И этим постом мы открываем серию публикаций, в которых будем освещать различные аспекты разработки приложений под Android, делиться опытом, как своим, так и других специалистов. Кстати, некоторое время назад мы уже писали об SDK и особенностях архитектуры YotaPhone, что тоже отчасти перекликается с темой данной публикации: полностью разработанная нами SDK построена по принципам, аналогичным стандартной SDK для Android, чтобы дать разработчикам интуитивно понятные инструменты.

Если вы разрабатываете приложения под Android, то вам, скорее всего, нужно где-то хранить данные. Вы можете выбрать один из облачных сервисов (в этом случае удобно пользоваться SyncAdapter) или воспользоваться встроенной SQLite-базой данных. Во втором случае вам придётся выбрать между записью SQL-запросов с помощью Content Provider (если вы планируете использовать данные несколькими приложениями) или ORM.

В этом посте мы рассмотрим некоторые из Android ORM, которые вы можете использовать в своих приложениях.

OrmLite

Пожалуй, это первый ORM, который приходит в голову. Однако это не Android ORM, а Java ORM с поддержкой SQL-баз. Его можно использовать везде, где применяется Java, например, в JDBC-соединениях, Spring и — Android.
Здесь активно используются аннотации, например, @DatabaseTable для каждого класса, определяющего таблицу, а @DatabaseField — для каждого поля в классе.
Простой пример использования OrmLite для определения таблицы:

Это open source-проект, вы можете найти его на GitHub. За более подробной информацией можно обратиться к официальной документации.

SugarORM

Этот ORM создавался именно для Android. В комплекте поставляется API, который легко изучить и запомнить. Он может сам создавать необходимые таблицы и содержит простые методы формирования связей по типу «один-с-одним» и «один-со-многими». Также SugarORM облегчает операции создания, чтения, обновления и удаления (CRUD) с помощью всего лишь трёх функций: save() , delete() и find() (или findById() ).
Чтобы использовать SugarORM в вашем приложении, нужно в AndroidManifest.xml добавить четыре тэга meta-data :

Теперь можно использовать этот ORM в классах, которые вы хотите превратить в таблицы:

Добавление нового пользователя:

Удаление всех пользователей в возрасте 19 лет:

Подробнее изучить возможности SugarORM можно в его документации.

GreenDAO

Если вам необходима высокая производительность, то обязательно присмотритесь к GreenDAO. Как сказано на их сайте, «большинство сущностей может быть добавлено, обновлено или загружено с производительностью несколько тысяч операций в секунду». И если бы авторы лукавили относительно возможностей своего детища, то оно вряд ли было бы использовано в этих всем известных приложениях. По сравнению с тем же OrmLite, GreenDAO почти в 4,5 раза быстрее:

По размеру он меньше всего на 100 Кб, что не имеет особого значения.
Посмотреть примеры использования GreenDAO можно в туториале, использующем Android Studio. Также желающие могут ознакомиться с кодом проекта на GitHub и изучить документацию.

ActiveAndroid

Как и многие другие ORM, ActiveAndroid помогает хранить и извлекать записи из SQLite без создания SQL-запросов.

Для использования ActiveAndroid нужно добавить jar-файл в папку /libs . Как сказано в начальной инструкции, нужно скопировать исходный код с GitHub и скомпилировать с помощью Maven. После подключения ActiveAndroid к вашему проекту, добавьте в AndroidManifest.xml тэги meta-data :

После этого можно при необходимости вызывать ActiveAndroid.initialize() :

Теперь вы можете, используя аннотации, создавать модели как Java-классы:

Это простой пример использования ActiveAndroid, для более сложных способов применения изучите документацию проекта.

Realm

Последний ORM в нашем обзоре, Realm написан на С++ и запускается прямо на вашем устройстве (без интерпретации), что обеспечивает очень высокую производительность. Код версии для iOS, если это кому интересно, можно найти на GitHub. Также на офсайте вы можете найти примеры использования Realm на языках Objective-C и Swift.

Источник

5 лучших ORM для Android

Если вы разрабатываете приложения для Android, то вам, скорее всего, нужно хранить данные. Если данных много, то для этого хорошо подойдет база данных SQLite. Для хранения данных в БД вам придется выбирать между SQL-запросами, используя Content Provider, или с помощью ORM .

ORM (англ. object-relational mapping, рус. объектно-реляционное отображение) — технология программирования, которая связывает базы данных с концепциями объектно-ориентированных языков программирования, создавая «виртуальную объектную базу данных». Существуют как проприетарные, так и свободные реализации этой технологии.ORM (англ. object-relational mapping, рус. объектно-реляционное отображение) — технология программирования, которая связывает базы данных с концепциями объектно-ориентированных языков программирования, создавая «виртуальную объектную базу данных».

В этой статье рассмотрю некоторые из ORM-библиотек, которые вы можете использовать в своих будущих проектах.

OrmLite

OrmLite первая ORM, которая приходит в голову. Однако OrmLite — это не Android-ORM, это Java-ORM с поддержкой баз данных SQL. Он может быть использован в любом месте где используется Java.

Аннотация @DatabaseTable служит для определения класса как таблицы, а аннотация @DatabaseField должна быть над каждым полем в классе.

Простой пример использования OrmLite

OrmLite для Android — это проект с открытым исходным кодом, который вы можете найти на GitHub . Для получения более подробной информации перейдите к официальной документации.

SugarORM

SugarORM это ORM, предназначен только для Android. Он поставляется с простым в освоении API, который легко запомнить. Всего есть 4 метода: save(), delete() and find() (or findById()).

Настроим приложение, чтобы использовать SugarORM, добавив мета-данные AndroidManifest.xml:

Теперь вы можете использовать эту ORM, унаследовав нужные классы от SugarRecord

Теперь добавим нового пользователя:

Удалим всех пользователей в возрасте 19 лет:

Для получения большей информации, читайте онлайн-документацию .

GreenDAO

Когда дело доходит до производительности, ‘быстрый’ и GreenDAO являются синонимами. На сайте библиотеки говорится, что “большинство объектов могут быть вставлены, обновлены и загружены со скоростью нескольких тысяч объект в секунду”. Если это не так уж хорошо, эти приложения просто не станет им пользоваться. По сравнению с OrmLite, это почти в 4,5 раза быстрее. Эту библиотеку используют довольно известные приложения такие как Pinterest, Path, WiFi Map Pro и другие. Эта библиотека почти в 4,5 раза быстрее OrmLite.

greenDAO против OrmLite

Библиотека весит меньше 100 килобайт, что не сильно повлияет на размер APK.

Вы можете просмотреть исходный код GreenDAO на GitHub , а также почитать официальную документацию GreenDAO .

Active Android

Как и другие ORM, ActiveAndroid позволяет хранить и извлекать записи из SQLite без написания SQL-запросов. Можно подключить ActiveAndroid добавив jar-файл в папку /libs вашего проекта.

После подключения его, вы должны добавить эти мета-данные в AndroidManifest.xml :

После добавления мета-данных, вы можете вызвать метод ActiveAndroid.initialize() в вашем Activity:

Теперь, когда приложение настроено на использование ActiveAndroid, вы можете создавать модели, как классы Java, используя аннотации:

Это простой пример использования ActiveAndroid. Документация поможет вам понять, как использовать ActiveAndroid ORM дальше.

Заключение

Это не все из существующих AndroidORM. Есть также Androrm и ORMDroid. Знание SQL — навык, который должен иметь каждый разработчик, но писать SQL-запросы скучно, особенно, когда есть так много ORM. Если они делают вашу работу проще, то почему бы не начать использовать их?

Источник

Сравнительное тестирование девяти ORM для Android

На просторах интернета много отрывочной информации о той или иной ORM для Андроид. Пока что мне не попадалось качественное сравнение ведущих ORM. Существующие статьи попахивают пиаром той или иной системы и ставят в невыгодное положение своих конкурентов либо некорректной постановкой тестирования, либо вообще использованием заведомо неверных настроек, либо не включением в тестирование сильных соперников.

Данное тестирование проведено было скорее для собственного интереса. Т.к. ORM много, все они разные, и хотелось бы иметь объективное представление о существующих системах.

За основу был взят репозиторий AndroidDatabaseLibraryComparison. Здесь их изначальная статья. Как видно автор сначала попытался не включить в обзор GreenDao, а когда его несколько раз попросили включил его с абсолютно неверными настройками, в результате чего “superfast Android ORM” оказался чуть ли не медленнее всех.

Отдельно хочу отметить, что большинство ORM все таки не полноценные и очень редко какая библиотека поддерживает запись и чтение объекта с вложенными коллекциями без танцев с аннотациями и отдельных подзапросов.

Методика тестирования

Тестировались 2 модели. Простая, т.н. POJO:

Простые типы, линейная структура. Данный объект создавался в 10000 экземплярах, экземпляры помещались в коллекцию и коллекция сохранялась средствами ORM в базу. Повторялось 6 раз.

На этапе чтения – коллекция считывалась, производилась сверка считаных полей во первых для контроля того, что данные были записаны и прочитаны, во вторых чтобы избежать хитрых Lazy чтений. После каждого считывания приложение закрывалось через менеджер задач и запускалось заново. Дело в том, что у некоторых ORM, таких как Realm, DBFlow и GreenDao есть свои кэши. И если считать сразу после записи, либо 2 раза подряд, чтение происходит их кэша практически мгновенно, что искажает общий результат. Да это можно считать как преимущество и следует учитывать при выборе ORM.

Сложная модель. Объект с вложенными списками:

Объект создавался в 50 экземплярах. Каждая вложенная коллекция так же заполнялась 50 экземплярами. Производилась запись. При считывании данные проверялись на корректность.

Каждый тест, опять же, проводился 6 раз. В результирующих графиках числа у столбцов — усредненные значения времени выполнения.

Результаты

Картинок много, поэтому под спойлером:

Простая модель. Запись:

Простая модель. Чтение:

Простая модель. Чтение без Sugar ORM:

Сложная модель. Запись:

Сложная модель. Чтение:

Сложная модель. Чтение без Sugar ORM:

Участники тестирования

1. Realm

Действительно очень быстрый. Действительно в некоторых случаях быстрее чистого SQLite (здесь следует отметить что в SQL использовался простой плоских алгоритм. Если подумать, то можно уменьшить число обращений к базе, использовав LEFT JOIN, но тут надо было думать, потом дебажить а мне было не охота, так что если есть желание — welcome). Что следует особенно подчеркнуть – очень простой во внедрении. Интуитивно понятен. Огромный плюс, это то, что Realm является полноценной ORM. Т.е. сохраняешь объект/считываешь объект: не нужно думать о внутренних коллекциях, их соотношениях, аннотировать безумными «Foreign. », «One-to-many. » ключами и прочими наворотам. Все работает их коробки.

Но есть и свои недостатки. Это все таки присутствуют странные падения с ассемблерным стеком в консоле. Да они очень редки, но есть. Все поля должны быть private, должен быть пустой конструктор и getter+setter каждому полю. Конечно в последних версиях появилась поддержка Lombok, но это еще +1 библиотека и +1 плагин в проект. Конечно и без Lombok это делается в 3 шортката в Android Studio, но это еще пачка boilerplate кода вам в проект. Кстати о размере: +5 мегабайтов к apk просто за подключение Realm.

Так же следует учитывать compile-time классы, которые не существуют до того как вы соберете первый раз проект. Сложности с Parceler, различия RealmResult и RealmObject, невозможности чтения объекта после realm.close(). Коллекции RealmList/RealmResult хоть и унаследованы от List, но не поддерживают многих базовых методов, таких как addAll, indexOf, toArray. Все это добавляет дополнительные проблемы. Конечно они решаемы, но сложность проекта возрастает и это тоже следует учитывать.

В целом работать с Realm приятно. Плюс: хорошая документация, практически все вопросы можно решить прочитав официальный сайт.

2. OrmLite

Очень старый и хорошо себя зарекомендовавший ORM. Одна проблема: последний релиз был 3 года назад. Много устарело. Сам подход устарел. Кодогенерация при наличии compile-time аннотаций в 2016 году? Вы серьезно хотите в это ввязаться? В целом показывает себя обычным середнячком. Где-то не 5-6м месте. Единственная приятная особенность: считывание вложенных коллекций автоматом при считывании родителя. Прямо как Realm. Только медленнее. Но у других ORM этого нет.

3. GreenDao

The superfast Android ORM for SQLite. Так заявлено на официальном сайте. И он действительно superfast. Иногда даже быстрее Realm. Но опять же кодогенерация. Вам придется создавать базу в отдельном проекте, при помощи дополнительных команд, потом его компилить и только тогда у вас появятся классы с которыми можно будет работать. Сгенерированые классы можно модифицировать, но следует помнить, что если не включить специальные комментарии, все они создадутся по новой при перегенерирации. Сама библиотека – быстрая и небольшого размера. Так что есть свои плюсы и свои минусы. Использовать или нет — решать вам.

4. DBFlow

Еще один фаворит по скорости (но не по удобству). Очень быстрая, как заявляли авторы — FASTEST ANDROID ORM DATABASE LIBRARY, но, мы видим, это не так. Annotation processing, т.е. генерация кода в процессе компиляции. Как следствие, например save() превращается в команды sql compileStatement, что обеспечивает наибольшую производительность. Потери скорости конечно на фабриках и рефлексии, куда же без этого. Поддерживает кэширование результатов, что позволяет получать данные из кэша практически мгновенно.

Но есть и минусы: библиотека развивается, сейчас в релизе 3я бета версия не совместимая со 2й. Половина официальной документации на 2ю, примеров мало, официальная документация неполная и порой вообще с ошибками. Глюки вылазят в самых неожиданных местах. Например если назвать имя pakage, в котором лежит ваш класс с большой буквы, проект у вас не скомпилируется. И вы даже не будете знать почему. Нормального текста ошибок нет. Проблемы с миграцией. Может если посидеть подольше, что-то и получится, но у меня миграция так и не взлетела, хотя все делал по примерам. В общем нужно вложить много человеко-часов чтобы начать пользоваться этот библиотекой нормально. Да что за примером далеко ходить, у самих авторов пример в этом тесте был не рабочий, пришлось доделывать.

5. Cupboard

Простая, не очень медленная, порой даже быстрая. Работает даже без аннотаций! Но для желающих, конечно, есть всякие @Ignore и даже Index. Единственная проблема – работает не от объекта, а от базы данных. Т.е. чтобы записать объект надо сделать примерно следующие манипуляции:

Что не всегда удобно. Плюс обязательно надо заводить поле Long _id у каждого объекта.

6. Sprinkles

Библиотека была добавлена в обзор не мной, но доделывал недостающие тесты я. Библиотека ужасна. Просто ужасна. Просто посмотрите на графики. Знаете почему так? Потому что авторы делают «SELECT * FROM %s WHERE %s LIMIT 1» на КАЖДУЮ запись в базу! Да да. Это авторы эмулируют «INSERT OR REPLACE». Причем выбора у вас нет. У вас есть только Save() и все. Считывание – простая обертка над sql: Query.many(AddressItem.class, «select * from AddressItem where addressBook=?», String.valueOf(id)).get().asList(). Это ORM? Правда? Механизма создания базы – нет вообще. Пишите «CREATE TABLE» вручную.

7. ActiveAndroid

Ну, что тут скажешь. Просто ORM без преимуществ. Скоростью не отличается.

8. Ollie

Еще один compile-time ORM. В целом довольно шустрый. Что-то сказать о преимуществах/недостатках не могу, т.к. не работал.

9. Sugar ORM

Простой, доступный, но ужасно медленный. Рефлексия на рефлексии с runtime-чтениями аннотаций выливается в очень медленную работу. До недавнего времени писал на каждую запись в базу «Log.i(SUGAR, object.getClass().getSimpleName() + » saved: » + id);». Если убрать эту строку – скорость записи возрастает иногда в 2 раза! Похоже авторы не озабочены производительностью в угоду простоты. Но с простотой тут все в порядке: минимум аннотаций, простые save(), find(), хотя, кого этим удивишь?

10. SQLlite.

Здесь речь пойдет про чистый SQL, нацеленный на максимальную скорость. Это «compileStatement» и bindString(i, value), да, да, по индексу, а не по имени. И никаких ContentValues. Только не в мою смену!

SQLlist безусловно в чистом виде практически всегда лидер. Исключение составляет только Realm на операциях комплексного чтения, вероятно дает знать nosql структура базы. Но, как я упоминал выше, уверен это можно оптимизировать.

Кто-то спросит, что означает на первом графике колонка «SQLite 50x»? Это multi-row запись, когда каждая вставка в базу делается по 50 объектов:

INSERT INTO table VALUES(?1, ?2, ?3), VALUES(?4, ?5, ?6), VALUES(?7, ?8, ?9)…

Это значительно усложняет код, поэтому я сделал его только для простого теста. В проекте на гитхабе этот код закомментирован.
Так же на чистом SQL особенно заметно влияние индексов и то, как замедляется запись в индексированную таблицу, и то как ускоряется чтение. Ну это уже прописные истины и использование индексов каждый должен выбирать под задачу.

Заключение

Безусловно тестирование не полное. Безусловно не учтены скорость случайного чтения. Так же нет тестирования на скорость инициализации ORM, т.е. время от момента создания самой обертки ORM до готовности работать с базой. Есть NoSQL вроде Snappy-DB, которые было бы интересно посмотреть в деле. Есть новые ORM вроде requery, о которых тоже мало что известно, но заявления у них как всегда громкие (поддержка RxJava, reflection-free и прочее).

Источник