CIST-CaTのデータ層コーディング
やること
データモデルの定義
jsonをそのままデータモデル変換するだけ
で上手くいく?
データモデル用のクラスとjsonを表現しただけのデータクラスを分離して記述する方法もある
DMMの新卒研修で使ったプロジェクトではそうしていた
メリットは?
API側の仕様変更に強い
デメリット
コード量が増加
やっぱりDTOも定義しよう
各種ドメインロジックの実装
Sheet
should_update:Bool
created_atから1週間経っているかどうかを静的に返す
実際にapiに問い合わせるのはusecaseの役割
いつ呼ばれる想定?
Activityのon_resumeをオーバーライドして呼びます
ほんとですか?
viewmodelのinitや、composeのlaunched Effectでもいいかも
うーん悩ましい
trueが返ってきたらsheetRepositoryにアクセスします
Timetable
get_outbound(d: Departure?):List<DepartureTime>
get_inbound(d:Departure ?):List<DepartureTime>
next_Bus(departure:Departure,now:LocalTime):LocalTime
これはいつ呼ばれる想定ですか?
CountDownTimerのon_finishedコールバック時に呼びます
DTOにはメソッドを定義しないことが多いようですt6o_o6t.icon
はいiNoma.icon
わかりづらいですねiNoma.icon
DTOはあくまでJSONを素直に表現するための中間層で、それとは別にドメインロジックを実装したクラスを書くつもりです
DTOとドメインクラスの変換などコード量が増えますが、データソース側の仕様変更に強いというメリットがある、と信じています(本当?)
サーバー側の仕様が変わることは大いにあり得ると思ったのでこうしていますiNoma.icon
なるほどt6o_o6t.icon
DTOのコンストラクタにドメインオブジェクトを渡す設計
package構成の整頓
moshiのセットアップ
converterを定義
LocalDateTime-String間のconverter
BusRemark-String間のconverter
moshiインスタンスを定義
converterをセット