Czy warto używać ORM w programowaniu Androida?

Czy ma sens użycie ORM w rozwoju Androida, czy też platforma jest zoptymalizowana pod kątem ściślejszego sprzężenia interfejsu użytkownika z warstwą DB?

Tło : Właśnie zacząłem od programowania Androida, a moim pierwszym instynktem (pochodzącym z tła .net) było poszukiwanie małego mapowania relacyjno-obiektowego i innych narzędzi, które pomagają zredukować grudkę płyty (np. POJO + OrmLite + Lombok ).

Jednak podczas rozwijania mojego pierwszego wniosku zabawki natknąłem się na klasy UI, który wyraźnie wymaga kursor bazy danych: AlphabetIndexer. To sprawiło, że zastanawiałem się, czy może biblioteka Androida nie nadaje się do ścisłego oddzielenia interfejsu użytkownika i warstwy DB i że przegapię wiele przydatnych, oszczędzających czas funkcji, jeśli spróbuję używać POJO wszędzie (zamiast bezpośredniego dostępu do bazy danych ).

Wyjaśnienie : Jestem w pełni świadomy zalet używania ORM w ogóle , jestem szczególnie zainteresowany tym, jak dobrze gra biblioteka klasowa Androida.

Android nie działa tak dobrze z innymi frameworkami, jak mógłby. Zalecany styl programowania zakłada, że ​​wszystko budujesz z API, bez innych bibliotek. Warstwa interfejsu użytkownika jest bardzo ściśle związana z modelem. Ten styl jest idealny do pisania mniejszych, modułowych aplikacji, a nie do złożonych aplikacji.

Musisz zastanowić się, czy chcesz mieć jakąkolwiek funkcjonalność Androida; jeśli go nie potrzebujesz, nie masz nic do stracenia przy użyciu ORM. Jeśli tak nie jest, być może będziesz musiał zadowolić się hybrydą. Użyj ORM do wszystkiego, co możesz, ale daj sobie haczyki do Cursorsi innych potrzebnych obiektów niskiego poziomu. Jeśli wybrany ORM wymaga DAO (nie znam tego, o którym wspomniałeś), to ta warstwa jest prawdopodobnie najlepszym miejscem dla nich.

Ewentualnie może nie być konieczne użycie zewnętrznego ORM. Jeśli Twoje potrzeby są proste, możesz napisać prostą warstwę dostępu do danych, która je spełnia. Większość wymagań bazy danych aplikacji nie jest świetna. Jeśli masz tylko kilka tabel, po prostu napisz kilka klas dostępu i obiektów modelu i nazwij to dobrym.

YAGNI i KISS są tutaj słowami kluczowymi do sukcesu. Proponuję spędzić kilka dni na prototypowaniu. Nie bój się wyrzucić prostych aplikacji testowych. Wypróbuj wszystkie swoje pomysły samodzielnie, a następnie zdecyduj, czy któreś z nich zadziała w Twoim projekcie.

To zależy od tego, co robisz z modelem danych. Jeśli masz istniejący kod, który manipuluje modelem obiektowym i jeśli chcesz zachować te obiekty w bazie danych sqlite, potrzebujesz orm.

Jeśli piszesz nowy kod systemu Android od zera, unikałbym modelu danych w pamięci, chyba że aplikacja wykonuje naprawdę skomplikowane operacje OO, jak na przykład program CAD. Ale w przypadku większości programów trzymaj model danych w bazie danych i pozwól, aby łańcuch obiektów kursorów, adapterów i widoków wykonał dla ciebie dużo wysiłku.