初めに
僕は C# のピンク本（※１）も読み終えていない頃、ASP.NET Core MVC のウェブアプリケーション開発に参加しました。
先行開発されていたソースコードを読みながら学び、学びながらコードを書く毎日。
すでにあったソースコードは、デザインパターンであるとの認識でした。
気づいてしまった問題点
でも
- #region で隠された、とっても長い Controller クラス
- Model はデータモデルと化し、Controller に長大なロジックが書かれている
- 多くの private メソッド（他の Controller からのコピペ跡も）
- View の中で暴れまわる Model
- Razor でアクセスできるからと言って、View の中に多くの判定文（＝ロジック）が書かれている
なんだか嫌な予感がするよ、R2。
学びの海へ
Head First のデザインパターン本第2版（※２）を開いてザックリ読んでみましょう。
MVC パターンについては P.520 から。
Model
モデルにはすべてのデータ、状態、アプリケーションロジックを格納します。モデルはビューとコントローラーには無関心ですが、状態の操作と取得のためのインターフェースを用意しており、また状態変化の通知をオブザーバーに送信します。
View
モデルの表示を行います。通常、ビューは表示に必要な状態とデータをモデルから直接取得します。
Controller
ユーザー入力を宇k鳥、ユーザー入力がモデルにとってどのような意味を持つか解釈します。
MVC の M の部分の説明が長い。つまり一番大切。逆に C の説明は短い。現状の実装はこれに則していない。おかしい！（安直）
Model が主役、View/Controller はシンプルに！
やったこと
View に渡すのはシンプルな ViewModel
- M の部分を、ロジックを持つ Model と、表示用の ViewModel に分ける
- View 内に複雑なロジックは持ちこませない
- 判定が必要な場合、判定結果を ViewModel で渡す
Controller からロジックを排し、徹底的に薄くする。
- Request の処理や認証などを除いてロジックをクラス化して委譲
- データ取得・計算
- 取得したデータや計算結果から ViewModel の生成
効果
MVC の役割が明確になった
- MVC パターンを生み出した先人への敬意
- Model が主役になる下準備
- 最も多い View の変更が Model/Controller へ飛び火しにくい構造に
Model にロジックが集まった
- ロジックの再利用性が高まった
- アプリケーションの中で大切なもの（ビジネスロジックやドメインモデル）がはっきり見えてきた
View からロジックが消えた
- 比較演算子がなくなった
- 深くへのメンバーアクセスがなくなった
Controller が Model と View を結ぶシンプルな橋渡し役になった
- 1000行以上あったコードが半分以下になった
個人的にはクラスを分割していくことで大切なルール、ビジネスロジックというものが見えてきたのが最大の効果だったと思います。
一子相伝のべた書き長大クラスを見つけたら、ちょっとずつでもいいのでロジックを分割して行こうと心に決めました。
おわりに
正直、この変更には結構な時間をかけちゃいました。今回書いた内容以外に DDD とかアーキテクチャーの話もあって、今尚旅の途中・・・
ソースコードレビューでチームメンバーにもさんざん協力してもらいました。
それに対して得られたものはほかのメンバーに伝わりにくいものかもしれません。しかし、確実に未来を形作るための第一歩になったと確信しております。
後悔は全くしていません。だって、変えたかったんだもん。
さぁ、皆さんご一緒に。
変えたい時が、書き換え時！
参考文献
※１「実戦で役立つ C#プログラミングのイディオム/定石&パターン」出井秀行（著） 技術評論社
非常にわかりやすく C# の入門書にもってこいだと思います。ただ C# 6（一部7）に準拠した内容で、物足りなさもあり。最新版の仕様に準拠して改版してほしいなぁ。
※２「Head First デザインパターン 頭とからだで覚えるデザインパターンの基本 第2版」Eric Freedman, Elisabeth Robson（著） O'REILLY
皆さんご存じ、にやにや読み進めることのできる珍しい技術書シリーズ。「紫のアレ」でなくなったことは少し寂しいですが、改訂版第一刷を購入できたことに深く感謝。