Androidの分離アーキテクチャ
Android用のアプリを作成しています。これには、誰が使用しているかに応じて複数のデータソースが含まれます。リポジトリパターンを使用したN層アーキテクチャは、これを行うのに適切な方法のようですが、苦労していますいくつかの基本ルールに固執しようとしています。
私が理解していることから、UIやDALについて実際に何も知らなくてもBLを記述できるはずです。私の問題は、UIレイヤーの作成を開始すると、バックグラウンドスレッドで実行するにはDALが必要であることに気付いたということです。これにより、BL/DALを変更して、UIレイヤーの要件に基づいて非同期でコールバックを実行するように強制する"NO"と叫ぶ。
ここに私が今持っている4つの層とそれらの依存関係があります。
[〜＃〜] ui [〜＃〜]-BLおよびCommon/Repositoryへの依存関係= Androidアクティビティ/フラグメント。UIレイヤーは、使用する具体的なリポジトリ/ DALタイプをBLに指示します
[〜＃〜] bl [〜＃〜]-Common/Repositoryインターフェースへの依存関係=ビジネスルールを含む個別のパッケージ。 UIレイヤーから渡された具体的なリポジトリを使用して、作業を行います
共通/リポジトリ-依存関係なし=他のすべてのレイヤーが知ることなく相互作用することを可能にするモデルとインターフェースを備えた個別のパッケージお互い。これもレイヤーと見なされますか？モデルは具象クラスまたはインターフェースである必要がありますか？
[〜＃〜] dal [〜＃〜]-Common/Repositoryパッケージへの依存関係=の具体的な実装を持つ個別のパッケージリポジトリ。 Commonに具象モデルがない場合、レイヤー間を通過するオブジェクトを作成するために、各レイヤーは独自の具象モデルを持つ必要がありますか？
何が欠けていますか？私はこれで私の快適ゾーンから自分自身を強制しようとしています:)
Androidでは、これに対する標準的な答えは、アクティビティ、フラグメント、アダプター、ローダー、サービスの組み合わせを使用することです。
私のプロジェクトでは、私たちは物事をどのように行うかについてかなり厳格です。アクティビティはベースビューを設定するために使用されます。これは通常、FrameLayoutまたはそれに類似したものです。そこにはUIロジックは一切ありません。アクティビティは、すべてを関連付けるために使用されます。 UIはすべてフラグメントによって処理されます（アクティビティのように扱う一部の特別なフラグメントを除く）。ネットワークの読み取りはすべてローダーで行われ、アダプターを使用してデータをUIにプッシュします。アダプタはフラグメントによって所有されますが、アクティビティはそれらをコールバックでローダーにワイヤリングします。サービスはネットワーク書き込みに使用されます。
このセットアップでは、インフラストラクチャのセットアップと基本的なワークフローの開発にかなりの時間を要しますが、作業パターンが得られたら、残りの部分をある程度自由に進むことができます。フローティングアクションボタンが必要です。適切なフラグメントを含めるだけで、基本クラスがボイラープレートを処理します。
つまり、最終的には、MVCではなくMVPスタックになります。私たちの見解は、ユーザーが何をしようとしているのかを認識し、インターフェースを介してそれを示します。典型的なワークフローは次のとおりです。
ユーザーが物事を見ていて、それに投票したい。賛成ボタンを保持するフラグメントがクリックをキャッチします。最初に、投票数をローカルで期待される新しい値に更新します。これは公式ではなく、どこにも永続化されないことに注意してください。投票が変更されていない最も一般的なケースでは、レイテンシが改善されるだけです。親（アクティビティまたはフラグメント）をupvote()メソッドを使用してインターフェイスにキャストし、それを呼び出します。アクティビティ（またはフラグメント）が賛成投票の呼び出しを取得し、コールバックを使用してサービスに渡します。サービスはアクションをキューに入れ（シングルスレッドで書き込み）、最終的にAPIを呼び出します。 APIは新しい投票数を返します。サービスは、ローダーにルーティングされるコールバックを呼び出します。ローダーはモデルの関連セクションを更新し、UIが取得して表示する新しいデータが利用可能であることをアダプターに通知します。モデルにパッチを適用するのが難しい場合は、ローダーが再要求するだけでよいことに注意してください。
したがって、これはかなり大きな一口ですが、ロジックは分離されており、UI全体はコンポジションを介して構築されており、コンポーネントはすべて高度にテスト可能であり、通常、バグが発生したときに何が起こったかを簡単に追跡できます。