ASP.NETアプリケーションのモダナイゼーションについて

モダナイゼーションとは？

老朽化した既存システムを現在のニーズに合うように刷新すること
ここでは、.NET Frameworkで構築されたシステムを.NETベースに刷新し必要に応じてUIを刷新します。

.NET Frameworkベースのアプリケーション

移行が比較的容易なグループ(.NETにも同様のフレームワークがある)
WindowsForm, コンソール, MVC...

移行が難しいグループ(.NETに同様のフレームワークがない)
WebForms....

でも、WebFormsのシステムって意外と多いよね。。。

なんで、モダナイしなければならないか？

コストメリットがないとモダナイなんてできないけども。

• コストの明瞭化（主にクラウドに移行する場合）
• 最新の機能を使用したい
• セキュリティの問題
• パフォーマンスの問題

だいたい以上のような理由に集約される

.NET Frameworkにとどまる選択

• メリットを十分に感じられない場合は.NET Frameworkのまま塩漬けにする選択も

• .NETにモダナイズするにはそれなりに開発費用がかかる

• メリットによって得られる利益と開発費用によってかかるコストとのバランスによって選択

• とはいえ、そのシステムが未来永劫続くとしたらどこかの時点で.NETにモダナイゼーションすることにはなるかも
  →やるかやらないかではなく何時やるかの選択

クラウドアプリケーションの場合

• .NET Frameworkのままの場合例えば、コンテナー化するとしてWindowsコンテナーですか？？
  App Serviceの場合今はよい。だが、いつまでホストできるのか？？

• セキュリティ面での不安はないか？？

• 様々な自動化を推進する上で障害にならないか？

最新の機能を実装したい場合

AIに関する機能を実装したい場合一応、Microsoft.Extensions.AIは.NET Framework4.6.1以降で対応だが言語機能的にいろいろ難しいところも。。。
サンプルなどはたいていC#12以降を念頭に書かれたものが多く読み替えが必要
たとえば、ストリーミングするのにawait foreachしたいけどもC#8.0など。

.NET Aspireとか使いたいですよね

• ローカルの開発段階でダッシュボードがあるだけでもデバッグやテレメトリー情報を使った性能分析ができて便利。

• 開発初期で遅いところを潰しておける効率的な開発ができる。

パフォーマンス改善

• .NETは毎年多くのパフォーマンス改善がされています。

• 特に大規模システムの場合はサーバーのサイジングを小さくできることによって得られるコストメリットが大きい

.NETのサポート期間について

• .NET FrameworkはOSのサポート期間に準じる

• .NETはLST(.NET 8など)はリリースより36ヶ月、STSは(.NET 9など)は18ヶ月

モダナイズにあたってやりたいこと

• 既存機能の断捨離
  業務プロセスの変化によって必ずしも全機能が使用されているとは限りません。
  費用圧縮のためにも機能の見直しは必ず行いましょう。

• 新規機能のフリーズモダナイズにあたって機能追加などは一旦フリーズしましょう。
  モダナイズと設計変更を同時に行うと既存機能を完璧に満たしながら機能追加かつモダナイゼーションしなければならなくなり難易度が上昇します。

モダナイの方法について

.NET Upgrade Assistant tool

• 自動で.NET Framework→.NETや.NETのバージョンアップ、診断などをしてくれるツール

• MVC、API、Windows Forms、WPFが対象

• 独自のコンポーネント・商用コンポーネントを使用しているとまあまあ手作業が増える

手動で頑張る

主に、Web Formsで構築されたシステムはこっちで頑張らなければ！

とはいえ、最近はGitHub Copilotもあるのでうまく立ち回れば省力化くらいはできるかも・・・
とはいえ、クラス設計とかその辺は人間駆動設計で頑張らないとぐだぐだに・・・

WebFormsのモダナイゼーションについて

このパターン多い！

推奨はBlazor Web Appsとはいえ事実上フルスクラッチ
Entra IDのテンプレもまだないつらみ・・・

既存の設計書 or ソースコードをインプットに内部仕様を参考にしてフルスクラッチで設計し直すしか

既存設計に引っ張られる and 基本設計はある程度Passできるので工数的にほぼ新規開発とかわらないレベル感

画面設計は再設計を考えた方がいい

AIを活用して頑張るのもひとつ

クラウドアプリケーションの考慮事項

ここは言語問わず共通事項かと思います。

多くのリソースはUTCで動作しています。JSTを前提にして動作してるアプリケーションは時刻について混乱します。

ノンカルチャーで動作します。
日本語カルチャーに依存するメソッドは動作しない・動作が変化する可能性があります。

タイムゾーンについての設計

内部的には日時をUTCで扱う→あらゆるシステムからUTCで日時が取得できるので自然
日時を表現する型はDateTimeOffsetを使用する
→時差を考慮した表現をしなければいけないので必然また、TimeProviderから返される型もDateTimeOffsetになっているので事実上標準
表示する時にViewまたはViewに近いところでJSTに変換する

カルチャーについて

stringクラスについては特に要注意
ローカルの単体テストを単純に実行しただけでは実行結果が変わることがある
→カルチャーを意識した単体テストの実施が必要

まとめ

費用対効果を考えて.NETにモダナイゼーションしていこう

とはいえ、そのシステムが続く限り（おそらく）いつかは通る道。やるかやらないかではなく何時やるかの問題