要約: URI をコンテンツ プロバイダー クラスの定数として定義する必要がありますか?それとも、テーブル ラッパー クラス定義に配布する必要がありますか? すべてを実装するためのより良い方法はありますか? 実装の唯一の好ましい方法はありますか? 相互依存を断ち切るには？
データベース テーブル ラッパー クラス: (抽象化レイヤーを作成するための) SQL コマンドの直接的な構築を避けるために、テーブルをラップするために、さまざまな定数といくつかの静的メソッドを使用して、以下のようなクラスが作成されます。
データベース ヘルパー クラス:データベース ヘルパー クラスは、データベースの抽象化です。上記のようなテーブルラッパーを使用して、より多くのテーブルをまとめてラップします。
コンテンツ プロバイダー クラス: AndroidXxxxContentProviderには、必要なデータをクエリ/挿入/更新/削除するためにさまざまな URI が送信されます。サブクラスは、そのContentProviderような名前のメソッドと他のいくつかのメソッドを実装する必要があります。各データ操作メソッドは (通常はUriMatcherインスタンスを使用して) URI を解析し、正確に何をすべきかを決定します。
更新:ContactsContract.java Android コア部分でを見つけました。それが相互依存を減らす方法ですか？それは、 「2 つの側面の間のことが複雑になりすぎたら、中間にエージェントを配置する」というような解決策ですか?