開発基盤部会 Blog

開発基盤部会 Blog >> 記事詳細

2020/11/25

Open棟梁 v1.0系 の新規採用、 マイグレーションの案内(第二版)

Tweet ThisSend to Facebook | by nishino
 先日の投稿(第14回 部会 Open棟梁の機能のデモを.NET 5でやってみる。)で、

 「BinaryFormatterに破壊的な変更が加わっており、コレについては、後日、情報を出す予定です。」

 と言っていた部分ですが、以前に書いた「Open棟梁 v1.0系 の新規採用、マイグレーションの案内」の第二版として、下記のように、情報を追加することにしました。

 この追加情報とは、


 レガシー物件でBinaryFormatter依存のモノをマイグレーションする場合のマイグレーション先は、.NET 5ではなく、.NET4.8の方が良いかもしれません。

 Web Forms は .NET Core、.NET 5に無いので、自動的に、.NET4.8でマイグレーションするか、.NET 5のMVCで再構築するか、となるのですが、同様に、3層C/S系のアーキテクチャは、BinaryFormatter依存なので、.NET4.8でマイグレーションするか、.NET 5で再構築した方が安全、

 (BinaryFormatterを自己責任で利用し続けることも可能と思いますが、今後、.NET 6.0 以降でBinaryFormatterがドロップされる可能性があり、その際に、代替手段が無いと難しくなります)

 ...と思います。

 と言う感じの情報で、

 経緯を辿ると、

 .NET Core3.0でデスクトップ系(Windows Forms、WPF)のサポートが追加される事となったので、レガシーの大多数もマイグレーションできるなぁ。...と思っていたんですが、.NET 5での「ちゃぶ台返し」で「BinaryFormatterの今後」次第では、3層C/S系は、マイグレーションが難しくなり、再構築が必要になる可能性が発生した。

 事に起因しています。

 ただし、

 BinaryFormatterが無くなると、ADO.NETのDataSet、DataTableなどの複雑なData Objectを、プロセス外に持ち出す手段がマルっと無くなってしまうので、その辺のケアって本当に.NET 5以降では無いんですかね?

 等と思ったりもしており、故に、
 今後も継続的にウォッチ予定です。



 まぁ、そんな、細かい話もあるのですが、

 (本投稿の締めとして、)大枠では、

 Open棟梁も、テクノロジの多様化の中、v2(Web系)、v3(DX系)と、引き続き、コンテンツを拡充していく予定ですが、中核のv1(業務系)の予算の獲得が出来なくなって、それによって、再び、素描や、オレオレ再開発が行われるのは、なんか、どうなの?と思ったりもしています。...が、結局、統合CASEから続く歴史を紐解いてみて、

  • サプライサイドとしては、
    セルフサポート化していく事と、
  • デマンドサイドとしては、
    セルフサポート化に対応していく事が

 重要(唯一のソリューション)になるのかな?

 等と思ったりしています。
09:00 | 投票する | 投票数(0) | コメント(0) | ご報告