SQL

SQL の条件を固定しない はじめに 改善前の実装 DAO にドメインの意味が入り込んでいた 問題意識 改善方針 改善後の実装 DAO：検索軸だけを知る Repository / UseCase：意味を与える この設計で得られたメリット 1. SQL / DAO の数が増えにくくなった 2. DAO の責務が明確になった 3. ドメインの変更に強くなった おわりに SQL の条件を固定しない DAO の責務を整理して、ドメインに意味を寄せる設計改善 はじめに Android アプリ開発において、 「とりあえず動く」状態から一段上の設計に進もうとすると、 ViewModel・UseCase・Repository・DAO の責務の境界で悩むことが多い。 今回は、 SQL で条件を固定していた実装を見直し 条件をパラメータ化して SQL の数を減らし その「意味」を Domain / UseCase 側で与える という設計改善を行ったので、その考え方をまとめる。 改善前の実装 DAO にドメインの意味が入り込んでいた もともと DAO には、次のような Query が定義されていた。 @Query("SELECT * FROM transfer_item WHERE isSourceItem = 1") fun observeSources(): Flow<List<TransferItemEntity>> この実装はシンプルで分かりやすいが、次の問題を抱えていた。 DAO が「Source（振替元）」というドメインの意味を知っている 条件が増えるたびに SQL / DAO メソッドが増える 将来的に Query が爆発する兆候がある 問題意識 ここで違和感を覚えたのは、次の点だった。 ...