メインコンテンツまでスキップ

19回大会前に書いてたコードの解説

ファイル構造​

shift_making_man
- Proglam.cs
- DataAccessFacade.cs
    Controllers
        shiftService
            - ShiftCreationService.cs
            - ShiftModificationService.cs
            - ShiftOptimizationService.cs
            - ShiftSchedulerController.cs
            - ShiftValidationService.cs
        - AuthController.cs
    Data
        Implementations
                - AdminDataAccess.cs
                - AttendanceDataAccess.cs
                - ShiftDataAccess.cs
                - ShiftRequestDataAccess.cs
                - StaffDataAccess.cs
                - StoreDataAccess.cs
        Interfaces
                - IAdminDataAccess.cs
                - IAttendanceDataAccess.cs
                - IShiftDataAccess.cs
                - IShiftRequestDataAccess.cs
                - IStaffDataAccess.cs
                - IStoreDataAccess.cs
        Models
            - Admin.cs
            - Attendance.cs
            - Shift.cs
            - ShiftRequest.cs
            - Staff.cs
            - Store.cs
        Views
            - DashboardForm.cs
            - LoginForm.cs
            - MainForm.cs
            - ShiftListForm.cs
            - ShiftSchedulerForm.cs

見ての通り構造化しまくって将来的な拡張性を重視した設計をした。というか、やりすぎ。

設計の方針​

  • コードの保守の面からセキュリティ気にしたらこうなっちゃった 保守の面から考えて、コードの役割分担するだけでエラーを追っかけやすくなるしどこが問題起こしてるか分かりやすいですよって言えばセキュリティの問題が発生した際の対応がやりやすいって言えると思った。大会本番に提示された資料として管理者からのヒアリングが追加されててそこに「個人情報扱うしセキュリティとか気にしてほしいな(要約)」っていうのも記載されてたのでMVC狂信者になって売り込み文句を書いてた。変更点が全体に響くわけではないので心臓にやさしいって言いたかった。ユニットテストはできるよ…ほんとだよ…

  • 将来的に機能拡張を想定してコードの拡張性を与えたかった 将来的に店舗の拡張や従業員の増加などに備えて変更する部分を最小限に、追加する際に動いてるコードに悪さしないように責任分担させれば安心安全に機能追加できるし、変更点も最小限に抑えられるからリリース早くなるぜって言ったらいいよってマーケティングの本に書いてあったからパクった

  • コードの可読性をあげたかった コードの可読性あげればさぁ…コード読みやすいじゃんかって思ったんですよ。機能追加がホイホイ行われるだろうし下手に1つにまとめて難読化するよりも構造化して読みやすくしてあげた方が優しいじゃないですかって思ったんですよ

方針通りに実装した結果がこれだよ!!!​

徹底した機能別のクラス設計​

なんかファイル名やらフォルダ名から察せる通り、命がけのMVC設計してます。そんな大規模システムじゃねえのに何してんだろう…一応ファイル名とフォルダ名からどういう機能が実装されてるか分かりやすくしたり、機能ごとに分けておくことで管理・デバッグ・機能追加・引継ぎで楽なことしかないので理にかなってます本当です

徹底した機能別設計によってデータの安全性もついでに保証​

下手にクエリを直書きしてないので事故が起きないようにしてある。そのためにコントローラークラスあるようなもの。

データベースにアクセスするのにどんな手順通ってるの?​

データベースにアクセスしてデータ持ってくるのに手順を踏んでいるのでそれの解説

1.依存性の注入​

使いたいテーブルに合わせてインターフェースをコンストラクタでコントローラーに注入する。 インターフェースは「I(テーブル名)DataAccess.cs」っていうファイル名になってるやつ。

備考

ここでいう「インターフェース」はモデルとクラスを中継するためのものです。

2.I(テーブル名)DataAccessメゾットを呼び出す​

実際のコードを見ればわかるかと思いますが、コントローラーでひたすらに「Iテーブル名DataAccess」インターフェースにあるメゾット呼び出しをしてるのでそれを元に「テーブル名DataAccess」にある紐づいているクラスを実行する。モックテストしやすい構造にしてる上、インターフェース側でコメントアウトすればクラスも動かないデバッグへのぬくもり

呼び出されたクラスを元にモデルのオブジェクトを変更する​

クラスごとに、削除や条件検索、変更などを割り当ててあるのでそれを実行する。フォームでユーザーが入力したり、アルゴリズムの実行中に存在する変数なんかの値を元にデータを取れるのでクエリを大量に書かずに済んだ。接続文を省略してないのは単純にガバ

備考

Springにあったアプリケーションプロパティとして全体に指定してくれるファイルが見当たらなくてどうしようもなかった接続文省略要素。あれ…Springだと標準実装じゃなかったっけ… Spring Data JPAを使えばリポジトリインターフェース作ってメゾット名によるクエリ自動生成がある程度効く上にカスタムクエリも作成できる素敵機能がある。しかも何なら今回の操作は9割方メゾット名クエリ自動生成が効くものだったので何度も「Spring使える環境を返して…」ってしながらコードを書いてた。

モデルを経由してテーブルからデータを取得・変更を行う​

モデルではテーブルのデータ型に合わせて取得するデータはこういうデータ型だと教えてあげる存在です。データベースにアクセスしてデータを取得する際、「プログラムで扱うときのデータ型はこれだ」と定義してやる存在です。ゴリゴリにMVC設計してるので詳しいことは別の場所でしっかり説明します。