Zenn
🐥

MVC の M と Service について

2023/07/10に公開
Web
MVC
model
c＃
クラス
tech

初めに

開発時点の私自身について

  • オブジェクト指向を業務でかっちり使わないまま、突然サイトを作らなくてはならなくなり、一通り出来上がって、MVC とはなんぞやと振り返っている
  • AWS SAA は持っているものの、実際に自ら開発するのは初めてであった
  • ちゃんと学習して向き合うのが当たり前だとは思っていたものの、短納期、かつ AWS 環境から何やら、HTMLデザイン以外、ゼロベースで、ほぼワンオペだったがゆえに、小さく動くところから始めるしかなかった

開発環境

  • 言語：C# MVC （.NET5 or 6）
  • 実行環境：Fargate, Elasticache Redis, DocumentDB, S3, ALB, CloudFront, WAF, Etc
  • パイプライン：Amazon Code シリーズ

MVC とは

  • 詳細は、詳しい方々が書いている内容や、書籍の内容だろうと思いますので、割愛

クラス設計

開発をする上で、必要なクラス設計すらしたことがなく、ネット上の記事などを参考にしながら進めていった
しかし、MVC の M って、本当にビジネスロジックなんだろうかと腑に落ちなかった

開発時の MVC 理解度

検索エンジンで出てくるようなイメージレベル、おおむねこんなだと思う

概要は分かった（つもり）ので、開発開始

デモ用のサイトを作らねば

  • ピュア PHP （というのか）で、ユーザーへ見せられる部分で開発

本番運用向けにはどうするか？

  • 所属会社は、Mircosoft 系のエンジニアが多いから、C# で行くことにした
  • 2021 年だし、.NET Framework は長い目で無いと判断、当時最新 .NET5 にした

AWS に関連する部分は？

  • AWS に詳しいメンバー（自分もそんなに詳しくない）には、資料を手厚く行く方針

Visual Stuio のプロジェクト構成は？

冒頭の通り、クラス設計もままならないまま、いったん着手（よくない例）

V はどうする

  • クラシックASP（死語）の構成でいったん仮組をする
  • 新卒時代に経験があったので、動くものベースで

C はどうする

  • コンテンツの種類分分けよう
  • 初期開発分は、動的とはいえ4 種類程度

さて、M はどうする

ここで、止まってしまい、このあたりって、心あたりあるのではないでしょうか

  • ビジネスロジックだよね？
  • データ加工だよね？
  • DB へのアクセスだよね？
  • あれ、パラメータストアって、ここか？
  • あれ、HTTP セッションの管理って？

と、M がモリモリになる

だけど、やるしかない。

開発着手直後の MVC の理解（イメージ）

どう見たって、M がやること多くないか？

再考しよう

  • View
    • 表示するデータを保持するクラスが必要だよね
      • どこ？
  • Controller
    • セッション管理は、Model じゃないよね？
      • どこ？
  • Model
    • やること多すぎだよね
      • 分ける？しかないよね

となる

プロジェクト構成

  • VS の階層で行くと
    • View は
      • View（.cshtml）
      • ViewModel とすれば良くない？
    • Controller
      • Controller
      • クラス設計には、Base という考え方があるぞ
        • セッション受け渡しをいったんそこにおいてみよう
          • 実際の保存読み込みはどこ？
      • ViewModel へデータを引き渡す元は、ServiceModel にしてみよう
        • データの受け渡しを簡略するメソッドをController に用意しよう
    • Model
      • Service という考え方があるぞ
        • ビジネスロジックは、Service クラスが良くないか？
        • データ加工用の Model は？
      • 業務ロジックにより、複数のモデルから加工などをしたデータは、ServiceModel に格納しよう
      • Repository という考え方があるぞ
        • データアクセス処理は、Repository クラスが良くないか？
      • データの受け渡しをするのはどうする
        • やっぱ Model だよな

だけど、これって、MVC なんだろうかと疑問は残った
このような構成に近しい説明があったサイトでは、開発規模に応じてなどと、どのレベルでService クラスや Repository クラスを使い始めるとよいかの指標がない

当時、上記の解釈としては、3 種類以上のコンテンツだったら、このレベルまで分けることに仮決めした

また、どこでも使いたい共通処理も置きたいよねとも思い、Utility クラスを用いることにした
そうでなければ、モヤっとするの

ということで、初学者レベルでは

こんな MVC イメージと内訳になった

インターフェースは？

当時全く理解していなかったため、考える余地がなかった。（いまも実務で使う機会がない）

で、結果どうだったか

  • ルール化して、意味合いをつけることにより、分け方として迷うことがなくなった
  • 最終形にたどり着くまで、何度もリファクタしたが、その分、納得感を得られた
  • このサイトのためのフレームワークがなかったが、考え方をフレームワークにした

課題

  • 初学者であるがゆえに、インタフェース定義した方が良かったよね、と気づけるようになる
  • 本来あるべき姿を指す書籍と比べくことにより、悩んで試行錯誤した結果があるからこそ、書籍への視点も多くなると思う

まとめ

  • クラスの Model と、概念的な Model について、分けて考えることにした
  • もちろん賛否どころか、けなされることもあると思うが、100% の答えがないと考えている
  • しかし、考え方の一つを示すことで、誰かのお役に立てることができればと思い、公開しました。

今後

  • 何かしらアップデートしていく可能性があるが、個人的には記録の意味合いが強いです

Discussion