私はAndroidアプリを論理コンポーネントに「パッケージ化」するための最良の方法を理解するのに苦労しています。私の目的は、更新や新機能の追加が簡単なアプリを作成することです。
「モジュラー」アプローチが最も効果的だと思います。データがデータクラスとして表され、DBにはすべてのDBインタラクションを処理する独自のDBヘルパークラスがあり、最後にDBヘルパーとインターフェイスする「コントローラー」アクティビティクラスを表示します。データクラスとビューをすべて一緒に。
そうは言っても、プログラミングを構造化するためにいくつかの高レベルのルールが必要です。ルールがないと、コードが複雑になりすぎて、コードがずさんになり、大規模な書き直しになってしまいます。
すべてを考慮すると、これらのルールはSQL対応アプリの優れた基盤ですか？
私の理論上のAndroidルール：
DBヘルパークラスには、すべてのDBロジックが含まれている必要があります。つまり、DBヘルパーには、DBを開いたり閉じたりするためのコードと、すべてのレコードを挿入、更新、および削除するためのコードが含まれます。DBヘルパーは、データをカーソルとしてではなく、私が作成したデータクラスオブジェクトとして返します。各データクラスには、カーソルを取得してクラスの値を設定するために使用するコンストラクターがあります。
データクラスを使用すると、DBレコードをカーソルだけでなくオブジェクトとして表すことができます。DBヘルパーはオブジェクトのみを返すため、カーソルではなくオブジェクトのデータをレンダリングするために、ListViewなどのアイテム用のアダプターを作成する必要があります（この点については少し怪しげですが、これが良いアイデアかどうかはわかりません。いいえ）。すべてのビジネスロジック、つまりデータクラスに含まれるデータに対して実行されるすべての計算は、データクラス自体で実行されます。私は、データクラスに典型的なゲッターとセッター、および「計算」メソッドがあることを想定しています。これらの計算メソッドは、データクラスから変数を取得し、それらに対して意味のあるビジネスロジックを実行して、結果を返します（これは良い考えですか？）。
ビューコントローラのアクティビティクラスは、文字通りDBヘルパーのメソッドをデータクラスに関連付け、結果の情報でビューを更新します。このアクティビティクラスは非常に正常で、レイアウトとウィジェットを初期化し、ライフサイクルメソッドを使用して適切なタイミングでDBヘルパーを介してDBに対してさまざまなクエリを実行し、ウィジェットを更新する単純な更新メソッドを備えています。それらが供給されるデータクラスオブジェクトを使用します。
このようなデザインの問題に苦労していることを除けば、Androidに問題はないことがわかりました。アプリケーションが複雑になりすぎることにうんざりしており、管理と拡張性を維持するためのシンプルなシステムが必要です。
私のように苦労した場合は、アプリを構築するための正しい方向に私を押してください。それが、私が誰もが楽しめる素晴らしいアプリになることを望んでいるものを作ることを妨げているすべてです。