11

私は現在、JSON 応答で構成されるファイルベースのデータベースを使用することが主なパフォーマンスの問題であるアプリケーションを持っています。

アプリケーションを書き直して、SQLite データベース機能を使用したいと考えています。
私は怠け者なので、何らかの ORM を使用したいと考えています。

これまでのところ、大きな ORM ライブラリは 2 つしか見つかりませんでした。

私の主な目標は、データ操作のパフォーマンスを可能な限り向上させることです

しかし、これらのライブラリには 2 つの問題がある可能性があることがわかりました。

  • ORMLite は注釈を使用します。これは、このバグによるハニカム以前の大きなパフォーマンスの問題です。

  • GreenDAO はある種のコード ジェネレーターを使用しており、ジェネレーターを作成してから生成されたコードを使用する必要があるため、開発が遅くなります。そして、私はこの考えがあまり好きではありません。

  • DB4O は JPA であり、メモリ使用量が遅く、メモリ使用量が多いため、ローエンド デバイスには適していないと常に考えていました (Android API v7 を思い出してください)。

ad @ChenKinnrot :
推定負荷は、ORM の使用を検討するのに十分なはずです。
私の場合、約 25 ～ 30 個の一意のテーブルと、少なくとも 10 個のテーブル結合 (一度に 2 ～ 4 個のテーブル) です。約 300 ～ 500 の一意のフィールド (列)

だから私の質問は：

  1. Android アプリケーションで ORM/JPA レイヤーを使用する必要がありますか?
  2. もしそうなら、どのライブラリを使用することをお勧めしますか? (そしていくつかの引数も追加してください)
4

5 に答える 5

4

私はORMLiteを使用しましたが、コツをつかめば（数時間）、非常に強力で、パフォーマンスの問題は発生しませんでした（HTCdesireとHTCHeroでGingerbreadでテストされたアプリ）。

DBを使用する必要のあるプロジェクトで再び使用します。

于 2012-07-13T14:37:32.877 に答える
2

ORM レイヤーは魅力的です。

ただし、実際には、単純な ORM を自分で作成するか、ORM とうまく連携しないコンテンツ プロバイダーパラダイムを使用します。

私はいくつかの既存の ORM ライブラリ (主に ORMLite 、activeAnroid ) を調べましたが、それらはすべて簡単に始めることができないようで、私を怖がらせました。

「25 ～ 30 の一意のテーブルと、少なくとも 10 のテーブル結合について話しています。約 300 ～ 500 の一意のフィールド (列)」

データのクエリ方法のパターンが固定されていて制限されている場合は、ORM/sql を自分で作成することをお勧めします。

私の2セント。

于 2012-07-13T14:35:05.700 に答える
1

アプリのパフォーマンスが心配な場合は、greenDAO をお勧めします。退屈なコードをたくさん書く必要がなくなるので、コード生成は問題になりません。その見返りとして、エンティティと DB ユニット テストも生成されます。

于 2012-09-25T15:48:29.307 に答える
0

共有する知識がいくつかあります：ORMは定義上、独自のSQLを作成するよりも遅く、データアクセスのコーディングを簡素化し、一般的なソリューションを提供すると想定されています.SQLをよく知っている場合、ジェネリック=クエリを作成するよりも遅く実行されます.

本当の問題は、どれだけ良いパフォーマンスを得たいかということです。可能な限り最高の場合、データマッピングフレームワークは考慮せず、より速く書くのに役立ちますが、すべてを完全に制御できるSQL生成フレームワークのみを考慮してください。

SQL データベースを最大限に活用したくない場合は、orm を使用してください。あなたが言及したこの orm の経験がないため、何を選択すればよいかわかりません。

また、DB はそれほど大きく複雑ではないため、orm で節約できる時間は問題になりません。

于 2012-07-13T14:25:43.947 に答える