6

Android アプリを開発し、クリーンなアーキテクチャのガイドラインに従おうとするときの最善のアプローチは何ですか (ただし、それほど厳密ではありません。小規模なプロジェクトではやり過ぎになる可能性があります)。

私の場合、データ層に関して どのアプローチが最適であるか (最善のアプローチがある場合) 、データ層が独自のモデル クラスで動作する必要があるのか​​、それともドメイン層モデルで直接動作する可能性があるのか​​がわかりません。

また、データレイヤーが独自のモデルクラスで動作する必要がある場合、データソースは独自のモデルを好むDBかAPI、独自のモデルを持っている必要があります（注釈付きのAPI使用RetrofitおよびGsonモデルクラスの場合など）。データレイヤーモデルにマップするか、データレイヤーモデル自体をおよびによって返されるモデル(これは、およびの場合に解析できるように、データ層モデルに注釈を付ける必要があることを意味します)。GsonDBAPIGsonRetrofitGson

これは、このプロジェクトの場合です 。

次の画像は、私が意味する 3 つのアプローチを明確にする必要があります。

イメージ 1では、DBとAPIが特定のモデル クラスを返します。の場合、次のAPIようになります (Retrofitとを使用Gson):

class ArticleResponse(@SerializedName("source") val source: SourceResponse,
                          @SerializedName("author") val author: String?,
                          @SerializedName("title") val title: String,
                          @SerializedName("description") val description: String?,
                          @SerializedName("url") val url: String,
                          @SerializedName("urlToImage") val urlToImage: String?,
                          @SerializedName("publishedAt") val publishedAt: String?)

Article次に、これらはローカル/リモート データ ソースによってモデル (ドメイン層で使用される)にマップされます。したがって、リポジトリはドメイン層モデルで動作し、境界を破っていますよね? それがアプローチ1です。 画像1

画像 2では、DBとAPIまだ特定のモデル クラスを返します。の場合、次のAPIようになります (Retrofitとを使用Gson):

class ArticleResponse(@SerializedName("source") val source: SourceResponse,
                              @SerializedName("author") val author: String?,
                              @SerializedName("title") val title: String,
                              @SerializedName("description") val description: String?,
                              @SerializedName("url") val url: String,
                              @SerializedName("urlToImage") val urlToImage: String?,
                              @SerializedName("publishedAt") val publishedAt: String?)

ただし、これらのモデルは、データ層が動作するデータ層モデル ( ArticleEntity) にマップされます。ドメイン層に応答するとき、これらはドメイン層モデルにrepositoryマップされます。これは境界を壊しませんが (右) 、 data-layer に追加のマッピングが必要です。これがアプローチ 2 です。ArticleEntityArticle

ここに画像の説明を入力

画像 3では、DBとはAPIすでにデータ層モデルを返していますArticleEntity。したがって、このモデル クラスには、API リクエストを解析するために必要なすべての注釈が含まれている必要があります ( を使用Gson)。

class ArticleEntity(@SerializedName("source") val source: SourceResponse,
                                  @SerializedName("author") val author: String?,
                                  @SerializedName("title") val title: String,
                                  @SerializedName("description") val description: String?,
                                  @SerializedName("url") val url: String,
                                  @SerializedName("urlToImage") val urlToImage: String?,
                                  @SerializedName("publishedAt") val publishedAt: String?)

DB に何らかのアノテーションも必要な場合は、これらもこのクラスに追加する必要があります (そうですか?)。私が考えることができるこのアプローチの利点は、モデル クラスが少ないことです (DB と API がデータ層モデルに直接マップされるため)。しかし、これはすべての異なるデータ ソース (DB、API) からの注釈/プロパティでデータ層モデル クラスを爆発させませんか? データ層モデルが特定のデータ ソースの実装に依存しているため (たとえば、Gson を使用して正確な API 応答名で API 要求を解析するなど)、リポジトリからデータ ソースを抽象化するという点全体が違反しているのではないでしょうか。これがアプローチ3でした。

ここに画像の説明を入力

私の質問は次のとおりです。3 つのアプローチのうち、最も柔軟で将来性のあるものはどれですか?

4

1 に答える 1

4

私があなたなら、Image1 プロセスを使用します。データベース、API、またはエンドポイントからのオブジェクトを取得し、リポジトリでユーザーが使いやすいものに変換するのは、データソースの仕事だと思います。

Image1とImage2の間で、保存したいデータと保存したいオブジェクトに依存すると思います。ビジネス ルールによっては、ArticleEntity が必要な場合と必要でない場合があります。必要ない場合は、作成する必要はありません。

しかし、ユースケースによっては、記事に情報を追加するためにそのオブジェクトを作成する必要がある場合があります。たとえば、リポジトリでのみ使用する有効期限やその他の情報をその中に入れたい場合は、Image2 を使用できます。

于 2017-12-20T11:05:44.077 に答える