Android開発でORMを使用するのは理にかなっていますか？

Android開発でORMを使用するのは理にかなっていますか、それともUIとDBレイヤー間のより緊密な結合のためにフレームワークが最適化されていますか？

背景：Androidの開発を始めたばかりで、最初の本能（.netの背景から来た）は、小さなオブジェクトリレーショナルマッパーや、ボイラープレートの負荷を減らすのに役立つ他のツール（POJO + OrmLite + Lombokなど）を探すことでした。

しかし、最初のおもちゃのアプリケーションを開発しているときに、データベースカーソルを明示的に必要とするUIクラスを見つけましたAlphabetIndexer。AndroidライブラリがUIとDBレイヤーの厳密な分離に適していないのではないかと疑問に思い、どこでもPOJOを使用しようとすると（データベースへの直接アクセスの代わりに）便利で時間を節約できる多くの機能を見逃してしまいます）。

明確化：ORM を一般的に使用する利点を非常によく知っています。AndroidクラスライブラリがORM と共にどの程度うまく機能するかに特に興味があります。

Androidは他のフレームワークとうまく動作しません。推奨される開発スタイルは、他のライブラリなしで、APIからすべてをビルドすることを前提としています。UIレイヤーは、モデルと非常に緊密に結合されています。このスタイルは、複雑なアプリケーションではなく、小規模なモジュール式アプリの作成に最適です。

Androidの機能のいずれかが必要かどうかについて考える必要があります。必要ない場合は、ORMを使用しても失うものは何もありません。そうでない場合は、ハイブリッドに落ち着く必要があるかもしれません。可能な限りORMを使用しますが、Cursorsおよび必要な他の低レベルオブジェクトへのフックを提供します。選択したORMにDAOが必要な場合（言及したものに詳しくない場合）、おそらくこのレイヤーが最適な場所です。

または、外部ORMをまったく使用しないでください。ニーズが単純な場合は、それらを満たす単純なデータアクセスレイヤーを作成できます。ほとんどのアプリデータベースの要件はそれほど大きくありません。テーブルが数個しかない場合は、アクセスクラスとモデルオブジェクトをいくつか記述して、適切な名前を付けます。

YAGNIとKISSは、ここで成功するためのキーワードです。数日かけてプロトタイプを作成することをお勧めします。簡単なテストアプリを捨てることを恐れないでください。すべてのアイデアを単独で試してから、プロジェクトの一部またはすべてが機能するかどうかを判断します。

データモデルをどうするかによります。オブジェクト指向モデルを操作する既存のコードがあり、それらのオブジェクトをsqliteデータベースに永続化する場合は、ormが必要です。

新しいAndroidコードをゼロから作成する場合、たとえばCADプログラムのようにアプリが本当に複雑なオブジェクト指向操作を実行しない限り、メモリ内データモデルを回避します。ただし、ほとんどのプログラムでは、データモデルをデータベースに保持し、Cursor、Adapter、およびViewオブジェクトのチェーンに多大な負荷をかけます。