出会い
初C#は、2013年末から半年ぐらい関わった開発メインのPJで、
「Silverlight × Spring .NET」という一風変わった組み合わせの案件だった。
発注元の要望でO/Rマッパーを一切使わない実装で、
Javaでいえば、JDBC＋マッパークラスは自前という古き良きスタイルだったので、
DBアクセス周りは、特筆すべきことは何もない。
発注元の自社エンジニアが技術力がないので、教育的観点から進んだ技術を使うのではなく、
開発初心者のサンプルアプリにもなるものにしたい、という話だった。
「Silverlight × Spring .NET」の組み合わせも顧客要望だった。
確かフロントは、ヌルサクのデスクトップアプリっぽく作りたいけど、
サーバーサイドは、発注元にJava出身者がいるので、その人にわかりやすいように作って欲しい、
とかだった気がする。
Visual Basicで作った.NETアプリケーションからのコンバートPJでもあった。
VBってあたりが時代を感じる。
Silverlightとは
HTMLやCSSなど通常のWebページの技術では困難な高い表現力や操作性を備えたアプリケーションをブラウザ上で実現することができる。
いわゆるRIA（Rich Internet Application）プラットフォームと呼ばれる技術の一つで、似た技術としてAdobe Flashがある。
Silverlightとは - IT用語辞典 e-Words
生みの親のMicrosoftにも見放された初期バージョンリリースから開発更新停止まで5年という短命な技術である。
次々と主要ブラウザのGoogle ChromeやFirefoxで動作しなくなり、もはやInternet Explorerと一緒に葬り去られる運命にある。
Spring .NETとは
JavaのSpring Frameworkの.NET版であるが、公式の活動は2012年を最後に息をしていない。
DIやAOPといったSpringが提供している仕組みが使える。
振り返ってみて
サーバーサイド担当だった自分にとっては、Camelで書くか、Pascalで書くか、ぐらいの違いしかなくて、C#でJavaっぽく開発したPJだった。
それもSpring使って、O/Rマッパー使わずにJDBCでDBアクセス部分を実装する、ような振り返ってみても奇妙なアーキテクチャである。
JavaとC#の記法の違いはこちらのサイトが詳しい。
Modelクラスを作った時に、Getter・Setterを書かなくて良かったので、それだけが印象に残っている。とはいえ、JavaでもLombokを使えば、同じことは出来る。
アーキテクチャ的には、MVVMモデルで作ったので、JavaのMVCモデルのWebアプリでそれまで開発していた身からすると、その点は、自分にとって新しかった。
ViewModelを定義してフロントエンドとサーバーサイド間で、状態を非同期で連動させていくスタイルは、当時のJavaのWebアプリに比べると圧倒的にUIが使いやすい印象を持った。
今で言えば、フロントエンドをVueか、Reactあたりで作って、サーバーサイドととは、JSONでやり取りするスタイルに近いのかもしれない。
「Silverlight」「Spring .NET」もどちらも.NET界隈主流の開発スタイルからは外れている。
６－７年経った今、その後のサポートとか大丈夫なんだろうか、と心配になる。
そういった意味では、流行り廃りも考慮した上でフレームワークを採用するのって重要だな、
と教えてくれたPJでもある。
「Silverlight」のXamlの技術とかは、元々WPFで使われているし、
「Spring .NET」のDipendency Injectionは、他のフレームワークでも普通に取り入れられている。
技術要素は、そのフレームワーク自体が廃れても新しいフレームワークに組み入れられていたりして、エンジニアからすれば、培った経験は無駄になることはない。
とはいえ、システム単体で見るとフレームワークの開発サポートが切れたりすると、一気に技術的負債の塊になる。脆弱性の問題もあるし、進化し続ける他のフレームワークと生産性の差は開くだろうし、提供できる機能にも制限がかかるだろう。
もしかしたら重要なのは、進化し続けるだろうフレームワークを当てることより、
外れても乗り換えが容易に出来るようにシステム構成を整えることなのかもしれない。