Orm android что это такое

ORM в Android c помощью ORMLite

На данный момент для платформы Android существует несколько решений, позволяющих реализовать ORM-подход для работы с базой данных, но основных два. Это ORMLite и GreenDAO.

Для новичков стоит сделать отступление и рассказать что такое ORM вообще. ORM — object-ralational mapping. Объектно-реляционное отображение означает, что программисту гораздо удобнее оперировать с объектами, которые он использует в своём приложении, нежели чем с таблицами, в которых хранятся данные в реляционных базах данных. Для связи реляционных СУБД с объектной моделью приложения используются ORM-технологии. Так для решения задач объектно-реляционного отображения в Android используют один из сторонних фреймворков. GreenDAO и ORMLite — являются библиотеками с открытым кодом.

GreenDAO

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

Преимущества:

Недостатки:

• Отсутствует механизм для переноса данных при обновлении схемы.
• Невозможность аннотирования классов, а необходимость описания алгоритма построения новых сущностей.

ORMLite

Популярный фреймворк для Java, имеющий адаптированную версию под Android.

Преимущества:

Недостатки:

… хм… я их не находил) всё что кажется не возможным, реализуется при более глубоком изучении доков.

OrmLite я использую в нескольких и проектах и знаком с ним достаточно тесно. Поэтому рассажу как раз о нем.

Простая аннотация классов

Каждый класс, отображение в базу данных (сохрание в БД) которого мы хотим сделать должен быть аннотирован. (можно использовать class-configuration, но это совсем другая история)Стоит заметить, что у класса должен обязательно присутствовать конструктор без аргументов. Пример аннотации:

Первая аннотация @DatabaseTable(tableName = «goals») указывает название таблицы, куда будут отображены объекты этого класса.
Перед каждым полем должна быть аннотация @DatabaseField с различными аргументами. (также можно не указывать аргументов — всё установится по умолчанию, а название столбца в таблице будет совпадать с названием поля). У поля name три аргумента. canBeNull = false означает, что в таблице этот столбец не может быть пустым. dataType = DataType.STRING принудительно обязывает приводить тип столбца к типу String . (доступные типы можно посмотреть здесь). columnName = GOAL_NAME_FIELD_NAME — принудительное указание имени столбца в таблице поможет нам в дальнейшем при построении select-запросов для получения данных из БД.
Первичным ключем может служить любое поле — достаточно указать у него id = true , но рекомендуется сделать автогенерируемое значение id и поставить ему generatedId = true . ORMLite сама назначит ему уникальный номер.
Для индексации столбца в БД указывается index = true
Полное описание всех доступных агументов аннотации полей можно посмотреть здесь
Также помимо аннотаций ORMLite можно использовать привычные некоторым javax.persistence аннотации

Подключение к SQLite в андроид

Существует несколько способов получения доступа к данным БД с помощью ORMLite в андроид. Можно наследовать каждую activity от ORMLiteBaseActivity и тогда нам не придется следить за жизненным циклом соединения с БД, но при этом мы не сможем получить доступа из других классов. (см примеры)
Гораздо предпочтительнее подход, рассмотренный далее.

Нужно создать класс, который будет инстанцировать помощника в создании и работе с БД:

Обращение к нему будет происходить во время начала и конца жизни приложения:
Это предотвратит утечки памяти из-за незакрытого соединения с БД

Так же не забываем описать наш класс наследник Application в манифесте:

Создадим класс DataBaseHelper, который будет отвечать за создание БД и за получение ссылок на DAO:

Как видно в примере, нужно описать создание полей и таблицы, а также реализовать получение ссылки на синглтон с DAO-объектом. Теперь рассмотрим непосредственно сами DAO.

Самой простой реализацией является следующий класс

Здесь создан лишь один дополнительный метод для получения коллекции всех объектов класса Role.
Основные методы create, update, delete реализованы в предке BaseDaoImpl.
Для обращения к методом класса RoleDao в любом классе приложения достаточно обратиться к классу-фабрике:
RoleDAO roleDao = HelperFactory.GetHelper().getRoleDAO();

Создание запросов

Для построения специфичных запросов можно создавать свои методы в классе DAO.

Как видно, здесь производился поиск по объектам с соответствующим полем имени.
При построении более сложных запросов помимо eq (что означает equals) есть и другие вроде gt (greater), ge (greater and equals) и остальных соответсвующих стандартным where-конструкцииям в SQL (полный список здесь)
Для построения сложного запроса можно добавлять and :
queryBuilder.where().eq(Goal.GOAL_NAME_FIELD_NAME, «First goal»).and().eq(Goal.GOAL_NOTES_NAME_FIELD_NAME,”aaa”);

Соответсвенно помимо запросов из БД подобным образом можно удалять и обновлять таблицы.

Работа с вложенным сущностями

Рассмотрим отношения вида много к одному. Допустим объект Goal имеет поле указывающее на Role.
Соответственно в классе Goal поле должно быть аннотированно

Теперь мы можем сохранить наши объекты в БД

Чтобы получить доступ к объекту класса Role, который связан с объектом типа Goal:

refresh() необходимо выполнять, чтобы r получил все поля из БД соответвующие этому объекту.

При хранинии ссылки на коллекцию подход немного отличается:

Аргумент в аннотации eager означает, что все объекты из roleList будут получаться из БД вместе с извлечением объекта типа Goal. Обязательной является ссылка на Goal в объекте Role. А так же нужно отдельно сохранять с помощью RoleDAO каждый из объектов Role.
Соответственно в классе Role должна быть аннотация:

Если не ставить eager=true , то будет осуществлена lazy-инициализация, т.е. при запросе объекта Goal объекты соотвествующие коллекции roleList не будут извлечены. Для их извлечения нужно будет произвести их итерацию:

Источник

ORM или как забыть о проектировании БД

От автора

Прошел год как я сменил профессию сетевого администратора на профессию программиста. За этот год было много необычного и странного. Удалось плотно поработать с sqlalchemy, взглянуть на ponyorm, поиграться с hibernate и nhibernate, освежить models из django… и знаете что? Весь код который я видел ассоциировался у меня с последствиями деятельности обезьяны имеющей запас гранат… оказалось что пускать программистов к бд — не самая лучшая затея. Под катом много боли и ненависти, но вдруг кому-то пригодится.

Прежде чем начать, хочу ввести пару допущений:

1. Весь текст представляет собой IMHO
2. Все имена и кейсы — синтетичны. Любое совпадение с реальными проектами и персоналями — случайность.
3. У автора большие проблемы с Великим и Могучим (боремся через личные сообщения)

Что такое ORM?

Прежде чем учить кого-то уму-разуму стоит понять что представляет из себя термин ORM. Согласно аналогу БСЭ, аббревиатура ORM скрывает буржуйское «Object-relational mapping», что в переводе на язык Пушкина означает «Объектно-реляционное отображение» и означает «технология программирования, которая связывает базы данных с концепциями объектно-ориентированных языков программирования»… т.е. ORM — прослойка между базой данных и кодом который пишет программист, которая позволяет созданые в программе объекты складывать/получать в/из бд.
Все просто! Создаем объект и кладем в бд. Нужен этот же объект? Возьми из бд! Гениально! НО! Программисты забывают о первой буковке абравиатуры и пхнут в одну и ту же табличку все! Начиная от свойств объектов, что логично, и, заканчивая foreign key, что никакого отношения к объекту не имеет! И, что самое страшное, многие тонны howto и example пропагандируют такой подход… мне кажется что первопричина кроется в постоянной балансировке между «я программист» и «я архитектор бд», а т.к. ORM плодятся и множатся — голос программиста давлеет над архитекторским. Все, дальше боли нет, только imho.

«Кто Вы, Мистер Брукс?» или «Что такое объект?»

Как определить «что такое объект» в ORM? Сколько человек смогут с первого раза донести весь смысл? Давайте я попробую.
Предположим что все мы живем на территории Белоруссии/Украины/России, прям как я. Согласно законодательству, в стране запрещены однополые браки и многоженство. При этом есть понятие «воинской обязанности» и прочих «специфичных» для каждого пола свойств. Что из этого следует?

1. Для каждого пола желательно (но не принципиально) иметь свою табличку
2. Где-то надо хранить информацию о принадлежности мужа жене и обратно

«Дык это ж OneToOne! Классика! Чего тут сложного? Определим fkey у строки для мужского или женского пола и побежали дальше» — ага, я умею читать мысли. НО! Наше ПО через год стало интересно арабским шейхам и они недоумевают, как так, не более 1 жены. Да и кому fkey добавлять? Мужскому полу? Женскому? А если все в одной таблице — кто напишет и будет сопровождать логику проверяющую что у дамы приклонного возраста не появится супруга?
Непонятно? Ок. Давайте псевдокодом:
man_1 = new Man()
man_1.name = «Иван»
woman_1 = new Woman()
woman_1.name = «Таня»
.
А что дальше?
man_1.wife = woman_1 или woman_1.husband = man_1
А как сохранить ЭТО в бд? А никак! В примере заведомо не верный подход к структуре данных!
Свойство name объектов woman_1 и man_1 — является свойством объекта ORM, а вот cвойство wife объекта man_1 и husband объекта woman_1 — это уже отношения объектов ORM! ЭТО РАЗНЫЕ СВОЙСТВА!
Все еще не понятно? Ок. Давайте еще более гуманитарным языком подойдем к вопросу.
Есть Иван и есть Татьяна. Если они забракуются то? Правильно! Они не изменятся! А если оторвать руки (или иной важный орган) Ивану и сбрить волосы Татьяне — они изменятся! Так вот, брак — отношение объетов, а руки и волосы — свойства объектов. Все, я не знаю как еще объяснить.

Тяжкое наследие ООП

Худо-бедно мы пришли к пониманию объекта. Стало вполне понятно кто есть кто. Но как ЭТО сохранить в бд? Некоторые товарищи с умными лицами и длинными бородами пропагандируют утверждение «все есть объект». Давайте попробуем придерживаться того-же, раз уж мы рассматриваем ORM. Допустим для объектов Man и Woman мы используем разные таблицы. Где будем хранить «объект» их отношения? Правильно! В ОТДЕЛЬНОЙ ТАБЛИЦЕ! Назовем ее woman_and_man . В табличке пока будет всего 2 колонки представляющих собой fkey: man_id и woman_id.
«Постойте, любезный, это уже ManyToMany какой-то!» — ага, я все еще читаю ваши мысли! Впринципе, я с вами соглашусь, с одной маааленькой поправкой. Если для таблицы woman_and_man определить правильные constraint — она легким движением руки превращается в OneToOne. Не верите? Пробуем!
Для случая OneToOne нам необходимо соблюсти следующие правила:

1. Одна женщина не может иметь более одного мужа мужского пола
2. Один мужчина не может иметь более одной жены женского пола

Введем соответствующие constraint:

1. значение man_id впределах таблицы woman_and_man должно уникально и не null
2. значение woman_id впределах таблицы woman_and_man должно уникально и не null

Все! У нас OneToOne!
Отправляем ПО на экспорт в ОАЭ — меняем constraint для man_id и получаем ManyToOne/OneToMany! Обратите внимание, структура таблиц не изменится, изменятся только constraint!
Отправляем ПО на экспорт в страну со взаимным многоженством/многомужеством (а есть такие?!) — меняем constraint для woman_id и получаем ManyToMany! Обратите внимание, структура таблиц не изменится, изменятся только constraint!
Проверьте ваши ORM — вы найдете пример использования OneToOne/ManyToOne/OneToMany через доп. таблицу.

Критикам посвящается

После высказывания своих мыслей руководителю я получил вполне ожидаемую реакцию: «Зачем так усложнять? KISS!»
Пришлось «набраться опыта»:

Были случаи с циклическими связями между объектами содержащими среди свойств fkey и задачей «бекапа/сериализации» этого безобразия в xml/json. Нет, бекапы то делаются, вот восстанавливать потом это безобразие чертовски сложно… необходимо жестко отслеживать какие свойства создаются при восстановлении/десериализации, а потом повторно проходить по объектам и восстанавливать связи между ними. Придерживаясь правила выше — надо сначала восстановить объекты, а уж потом связи между ними. Т.к. хранится эта информация в разных таблицах/сущностях — логика была линейной и простой.

На каждый выпад «возьми монгу и не парься» или «документо-ориентированые бд рулят» я всегда приходил к одному и тому же результату который еще никто покрыть не смог:
Я смогу создать схему в реляционной бд которая будет сохранять произвольную структуру данных (произвольные документы), а вот сможете ли вы в документо-ориентированой бд гарантирвать целостность данных на уровне реляционых бд? Я не смог достич такого уровня.
Никого не смущает множественные куски повторяющихся документов с произвольным уровнем вложенности? Не, я знаю что их хранение оптимизировано и вобще, тебе какая разница? Но все же.

Источник

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. Если они делают вашу работу проще, то почему бы не начать использовать их?

Источник