ディレクトリ構成

DiQtの設計は、「View + Model + Repository」となっています。

以下は、lib以下のディレクトリの役割とファイルとクラスの命名ルールの説明です。

pages

• 役割： ページの大枠を構成するWidget。
• クラス名の命名ルール： 親ディレクトリ名 + ファイル名 + Page
• 例
  • ファイル名： pages/user/edit.dart
  • クラス名： UserEditPage 　 　

components

• 役割： ボタンなどのUIを構成する個々のWidget。
• クラス名の命名ルール： 親ディレクトリ名 + ファイル名
• 例
  • ファイル名： components/user/achievements_button.dart
  • クラス名： UserAchievementsButton 　 　

　

utils

• 役割： 外部ライブラリのラッパー(xxx_service.dart)や、データの入出力や設定や便利メソッド（xxx_handler.dart）など。
• ファイル名の命名ルール： ライブラリのラッパーはservice、その他の便利メソッドはhandlerやその他の名詞形で設定する。
• クラス名の命名ルール： ファイル名
• 例
  • ファイル名： utils/dialogs.dart
  • クラス名： Dialogs
  • ファイル名： utils/purchase_service.dart
  • クラス名： PurchaseService

data

• 役割： Repository層。データソースにアクセスするために必要なロジックをカプセル化する。

local

• 役割： ローカルデータ（FlutterSecureStorage）にアクセスする。
• クラス名の命名ルール： Local + ファイル名
• 例
  • ファイル名： data/local/user_info.dart
  • クラス名： LocalUserInfo

remote

• 役割： （主にDiQtの）APIにアクセスする。
• ファイル名の命名ルール： DiQtのAPIへのアクセスなら、Railsのコントローラーと命名を合わせて複数形にする。
• クラス名の命名ルール： Remote + ファイル名
• 例
  • ファイル名： data/remote/users.dart
  • クラス名： RemoteUsers

provider

• 役割： Riverpodのproviderの設定

model

• 役割： model層。 Rails側のmodelを模倣する。
• ファイル名の命名ルール： 単数形。