Чи має сенс використовувати ORM в розробці Android?

Чи має сенс використовувати ORM в розробці Android чи оптимізована рамка для більш жорсткої зв'язку між інтерфейсом користувача та рівнем БД?

Передумови : Я щойно розпочав розробку Android, і моїм першим інстинктом (з фоном .net) було шукати невеликий об'єктно-реляційний картограф та інші інструменти, які допомагають зменшити кількість закритих шаблонів (наприклад, POJOs + OrmLite + Lombok ).

Тим НЕ менше, при розробці мого першого додатка іграшки я натрапив на клас UI , який явно вимагає курсору бази даних: AlphabetIndexer. Це змусило мене замислитись, чи, можливо, бібліотека Android не підходить для суворої розв'язки інтерфейсу користувача та рівня DB, і що я пропущу багато корисних функцій, що заощаджують час, якщо я спробую використовувати POJO скрізь (замість прямого доступу до бази даних ).

Пояснення : я цілком усвідомлюю переваги використання ORM взагалі , мене спеціально цікавить, наскільки добре бібліотека класів Android працює разом із ним.

Android не грає так чудово з іншими рамками, як міг. Рекомендований стиль розробки передбачає, що ви створюєте все з його API, без інших бібліотек. Шар інтерфейсу дуже щільно з'єднаний з моделлю. Цей стиль ідеально підходить для написання менших модульних додатків, а не для складних програм.

Вам потрібно задуматися, чи хочете ви будь-яку функціональність Android; якщо він вам не потрібен, ви нічого не втрачаєте, використовуючи ORM. Якщо це не так, можливо, вам доведеться погодитися з гібридом. Використовуйте ORM для всього, що можете, але надайте собі гачки для Cursors та будь-яких інших об'єктів низького рівня, які вам потрібні. Якщо ORM, який ви вибрали, вимагає DAO (я не знайомий з тим, про який ви згадали), то цей шар, мабуть, найкраще місце для них.

Крім того, вам може знадобитися взагалі не використовувати зовнішньої ORM. Якщо ваші потреби прості, ви можете написати простий рівень доступу до даних, який відповідає їм. Більшість вимог до бази даних програм не великі. Якщо у вас є лише кілька таблиць, просто напишіть пару класів доступу та об'єкти моделі та назвіть це добре.

ЯГНІ та KISS - ключові слова успіху тут. Я пропоную вам витратити кілька днів на прототипування. Не бійтеся викидати прості тестові програми. Спробуйте всі свої ідеї самостійно, а потім вирішіть, чи буде працювати якийсь чи всі для вашого проекту.

Це залежить від того, що ви робите зі своєю моделлю даних. Якщо у вас є код, який маніпулює об'єктно-орієнтованою моделлю, і якщо ви хочете зберегти ці об'єкти в базі даних sqlite, вам потрібна орма.

Якщо ви пишете новий код Android з нуля, я б уникнув моделі даних в пам'яті, якщо додаток не виконує дійсно складні маніпуляції OO, як, наприклад, програма CAD. Але для більшості програм зберігайте модель даних у базі даних, і дозвольте ланцюжком об'єктів Cursor, Adapter та View зробити багато важкого підйому для вас.