開発基盤部会 Blog

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

2018/08/02

ASP.NET MVCとWebAPIのサンプルをPOCOベースのスタイルに変更して思ったこと。

Tweet ThisSend to Facebook | by:nishino
 エンジニア界隈に長く居ると、最新技術が出て来る度に、「XXXは死んだ。」・「コレからはYYYだ。」的に言われたり、書かれたりすることを、既に何回も目にしてきた諸兄も多いかと思いますが、前回、言及した「STP(セグメント/ターゲット/ポジション)」を考えると、このような技術ブログはミスリードが多い。ということを、薄々勘付いてはいましたが、本件で確信した次第です。

 本件で、具体的に何をしたか?という話ですが、Open棟梁の動的パラメタライズド・クエリのインターフェイスが System.Data ベースだったので、 ASP.NET MVC の POCO ベースのスタイルにフィッティングさせるために、(AutoMapper があまり使えなかったということもあり、)下記のissueで、System.Data ⇔ POCO の Mapper を自作し、 ASP.NET MVC と WebAPI のサンプルを POCO ベースのスタイルに変更してみました。


 一時期、「System.Data 死亡 → Entity Framework or Dapper への移行」説が流れ、動的SQL や DataTable & RowState を使用したいエンタープライズ・アプリケーションのアーキテクト的には「?」だったんですが、 System.Data から POCO にフィッティングさせて STP 次第でコンパチ出来る所まで手元に手繰り寄せたら、

 「Java / Ruby の POCO 文化を取り込んだ ASP.NET MVC を使用する場合、 Model Binding で POCOベースのスタイルであったほうが効率は良いが、 ORM 自体は必須の要件ではない。

 と、やっぱり、この手の情報はミスリードである。と解ります。

 因みに、System.Data の DataTable も .NET Core 2.0 でサポートされましたし、 Windows Forms も .NET Core 3.0 に取り込まれる予定で、Windows Forms + DataGridView + DataTable + RowState による一覧更新処理実装は、RAD (Rapid Application Development) の「極地」として今後も利用可能になるだろうと思われます。

<参考>

 以下の情報は、今回の逆のパターンで、POCO文化をDataTable文化にハメようと言うケースで、これも、これで示唆的です。基本的に適合するものを使用すれば良いのですが、異文化のプロダクト同士のフィッティングをする際は、親和性も考慮する必要がありそうです。


09:00 | 投票する | 投票数(0) | コメント(0) | ご報告