2017年03月10日
川俣晶の縁側ソフトウェア技術雑記total 1655 count

ASP.NET MVCは本当に使いやすいのか?

Written By: 川俣 晶連絡先

「取りあえず、ASP.NET MVCは本当に使いやすいのか?という疑問をここでまとめておこう」

「ふむふむ。何が言いたいのだ?」

「ASP.NET MVCは効率が良くない。最初は慣れていないからだと思ったがそうでもないと思うようになってきた」

「説明してくれよ」

大前提 §

「話の大前提だ。Webアプリを構築する技術として、ASP.NETにはWebフォームとMVCが存在する。両者の利用領域は重なっていて、かつ比較しうるものだ」

「うん」

「それからWebアプリについての特徴もまとめよう。Webアプリには以下の3つの制約が付いて回る」

  • 全てのユーザーが1つないし少数のサーバーを共有して性能にクリティカルである
  • サーバーとは高速ではないかもしれない回線で接続されているが予測できない
  • クライアント側のコードはJavaScriptで実行されるがあまり生産性は高くない

「うん」

「従って、適切な負荷分散は常に要求されている世界だと言える。しかし、単に分散すれば良いという話ではなく、回線の負荷も上げてはならない制約を持つ」

「そうだね」

「ここまでが話の大前提」

論理モデルの破綻 §

「さて、ASP.NET MVCは物理的な制約ではなく論理的な役割でMVCの3つに構成要素を分割することになる」

「モデル、ビュー、コントローラだね」

「ところが、Webアプリは負荷を最小化するために物理的に設計される必要があり、論理的な分割とは馴染まない。構造に無理が出てきてしまう」

「つまりなんだい?」

「割と、モデルが存在しなかったり、ビューがスケルトンだけで事実上コントローラでページを構築してしまうコードが産まれやすい」

「それはMVCモデルの正しい使い方ではないね?」

「その通りだが、MVCモデルの正しい使い方をしても別に性能は上がらないし、生産性も上がらない。むしろ下がってしまう」

「コードがモデルに沿っていれば分かりやすくなって、メンテナンス性は上がるんじゃないか?」

「逆なんだよ。かえって構造が過剰に複雑化してメンテナンス性が下がってしまうんだ」

「えー」

ディレクトリ構造的の問題 §

「ASP.NET MVCはディレクトリ構造が仮想化されていて、物理的に同じフォルダに入っているものが論理的に同じフォルダに対応するとは限らないという問題がある。それらはカスタマイズ可能ではあるが、非常に分かりにくく、見通しを悪くしている」

「デフォルト状態だとビューを置くフォルダを浅くも深くもできないってことだね」

「もちろんカスタマイズはいくらでもできるよ」

「でも、そのカスタマイズが迷宮の入口なのだね?」

「そう。誰がどんなカスタマイズをするか分かったものではない。メンテナンス性は下がるだろう」

分割単位の問題 §

「Webフォームの場合、フォームとコードが一対一の関係で難しくない。ところが、ASP.NET MVCになると、ビューは1ページで1ファイルだが、なぜかコントローラはディレクトリ単位で一つのファイルなのだ」

「対応関係が分かりにくいね」

「しかも、ディレクトリとページの関係が硬直的で簡単にページを移動できなくなる」

「ビュー(cshtml)は移動させるだけで良くても、コントローラはファイルからメソッドを切り出して別のファイルに貼り付けねばならないわけだね」

「そう。そして、ソースファイルを移動させたメソッドはそのままコンパイルできるかどうか分からない」

「依存メソッドが呼べないとか、using足りないとか、いろいろ面倒なことが起こりうるわけだね」

感想 §

「結局、MFCの時に破綻したモデル-ビュー構造の亡霊が蘇って再度襲来した感じだが、今回はもっと悪い」

「なぜ悪いの?」

「疎結合分散処理という難物と合体してしまうと手が付けられない暴れん坊になってしまいかねない」

「でも、メンテナンス性を維持するには論理モデルを整理するのは避けられないことではないの?」

「理屈の上ではその通り。でも大多数のWebアプリはメンテナンス性で悩むほど複雑なコードを書かない。ページ単位で見れば悩むほど複雑なことはやらないことが大半」

「ふむふむ」

「しかも、クライアント側に大規模コードを置くケースも増えて来ているので、サーバ側のモデルにどれほどの意味があるのか」

「ASP.NET MVC APIの利用を検討する方が良いわけだね?」

「APIはAPIで、同じコードが使えなかったり、ブラックボックスが増えて分かりにくくなる問題もあるからなあ。XMLでもJSONでも通信できるがブラックボックスで隠されて見えにくい」

「果てしない迷宮か」

「まあ、素人の飴細工みたいな技術を未来の本命だと言い切って増築に増築を重ねたのがWebの世界だからな」

「トラブルシューティングのことを考えれば構造が全部見える方が有り難いのに、仮想化して隠した方が簡単になると思い込んだ技術が多いってことだね」

「トラブル発生時の調査負荷はWebフォーム時代の数倍数十倍に膨れあがっているようにも思える。見えない部分でどこから意図しない動作になっているかを調べられないんだ」

Facebook

キーワード【 川俣晶の縁側ソフトウェア技術雑記
【技術雑記】の次のコンテンツ
2017年
04月
12日
Windows 10 Creators UpdateのIEで【Edgeを開く】ボタンを消す
3days 3 count
total 1877 count
【技術雑記】の前のコンテンツ
2017年
03月
08日
Visual Studio 2017 RTWが来た
3days 2 count
total 1358 count
2017年03月10日
川俣晶の縁側ソフトウェア技術雑記total 1655 count

ASP.NET MVCは本当に使いやすいのか?

Written By: 川俣 晶連絡先

「取りあえず、ASP.NET MVCは本当に使いやすいのか?という疑問をここでまとめておこう」

「ふむふむ。何が言いたいのだ?」

「ASP.NET MVCは効率が良くない。最初は慣れていないからだと思ったがそうでもないと思うようになってきた」

「説明してくれよ」

大前提 §

「話の大前提だ。Webアプリを構築する技術として、ASP.NETにはWebフォームとMVCが存在する。両者の利用領域は重なっていて、かつ比較しうるものだ」

「うん」

「それからWebアプリについての特徴もまとめよう。Webアプリには以下の3つの制約が付いて回る」

  • 全てのユーザーが1つないし少数のサーバーを共有して性能にクリティカルである
  • サーバーとは高速ではないかもしれない回線で接続されているが予測できない
  • クライアント側のコードはJavaScriptで実行されるがあまり生産性は高くない

「うん」

「従って、適切な負荷分散は常に要求されている世界だと言える。しかし、単に分散すれば良いという話ではなく、回線の負荷も上げてはならない制約を持つ」

「そうだね」

「ここまでが話の大前提」

論理モデルの破綻 §

「さて、ASP.NET MVCは物理的な制約ではなく論理的な役割でMVCの3つに構成要素を分割することになる」

「モデル、ビュー、コントローラだね」

「ところが、Webアプリは負荷を最小化するために物理的に設計される必要があり、論理的な分割とは馴染まない。構造に無理が出てきてしまう」

「つまりなんだい?」

「割と、モデルが存在しなかったり、ビューがスケルトンだけで事実上コントローラでページを構築してしまうコードが産まれやすい」

「それはMVCモデルの正しい使い方ではないね?」

「その通りだが、MVCモデルの正しい使い方をしても別に性能は上がらないし、生産性も上がらない。むしろ下がってしまう」

「コードがモデルに沿っていれば分かりやすくなって、メンテナンス性は上がるんじゃないか?」

「逆なんだよ。かえって構造が過剰に複雑化してメンテナンス性が下がってしまうんだ」

「えー」

ディレクトリ構造的の問題 §

「ASP.NET MVCはディレクトリ構造が仮想化されていて、物理的に同じフォルダに入っているものが論理的に同じフォルダに対応するとは限らないという問題がある。それらはカスタマイズ可能ではあるが、非常に分かりにくく、見通しを悪くしている」

「デフォルト状態だとビューを置くフォルダを浅くも深くもできないってことだね」

「もちろんカスタマイズはいくらでもできるよ」

「でも、そのカスタマイズが迷宮の入口なのだね?」

「そう。誰がどんなカスタマイズをするか分かったものではない。メンテナンス性は下がるだろう」

分割単位の問題 §

「Webフォームの場合、フォームとコードが一対一の関係で難しくない。ところが、ASP.NET MVCになると、ビューは1ページで1ファイルだが、なぜかコントローラはディレクトリ単位で一つのファイルなのだ」

「対応関係が分かりにくいね」

「しかも、ディレクトリとページの関係が硬直的で簡単にページを移動できなくなる」

「ビュー(cshtml)は移動させるだけで良くても、コントローラはファイルからメソッドを切り出して別のファイルに貼り付けねばならないわけだね」

「そう。そして、ソースファイルを移動させたメソッドはそのままコンパイルできるかどうか分からない」

「依存メソッドが呼べないとか、using足りないとか、いろいろ面倒なことが起こりうるわけだね」

感想 §

「結局、MFCの時に破綻したモデル-ビュー構造の亡霊が蘇って再度襲来した感じだが、今回はもっと悪い」

「なぜ悪いの?」

「疎結合分散処理という難物と合体してしまうと手が付けられない暴れん坊になってしまいかねない」

「でも、メンテナンス性を維持するには論理モデルを整理するのは避けられないことではないの?」

「理屈の上ではその通り。でも大多数のWebアプリはメンテナンス性で悩むほど複雑なコードを書かない。ページ単位で見れば悩むほど複雑なことはやらないことが大半」

「ふむふむ」

「しかも、クライアント側に大規模コードを置くケースも増えて来ているので、サーバ側のモデルにどれほどの意味があるのか」

「ASP.NET MVC APIの利用を検討する方が良いわけだね?」

「APIはAPIで、同じコードが使えなかったり、ブラックボックスが増えて分かりにくくなる問題もあるからなあ。XMLでもJSONでも通信できるがブラックボックスで隠されて見えにくい」

「果てしない迷宮か」

「まあ、素人の飴細工みたいな技術を未来の本命だと言い切って増築に増築を重ねたのがWebの世界だからな」

「トラブルシューティングのことを考えれば構造が全部見える方が有り難いのに、仮想化して隠した方が簡単になると思い込んだ技術が多いってことだね」

「トラブル発生時の調査負荷はWebフォーム時代の数倍数十倍に膨れあがっているようにも思える。見えない部分でどこから意図しない動作になっているかを調べられないんだ」

Facebook

キーワード【 川俣晶の縁側ソフトウェア技術雑記
【技術雑記】の次のコンテンツ
2017年
04月
12日
Windows 10 Creators UpdateのIEで【Edgeを開く】ボタンを消す
3days 3 count
total 1877 count
【技術雑記】の前のコンテンツ
2017年
03月
08日
Visual Studio 2017 RTWが来た
3days 2 count
total 1358 count
【技術雑記】のコンテンツ全リスト【技術雑記】の表紙

このコンテンツを書いた川俣 晶へメッセージを送る

[メッセージ送信フォームを利用する]

メッセージ送信フォームを利用することで、川俣 晶に対してメッセージを送ることができます。

この機能は、100%確実に川俣 晶へメッセージを伝達するものではなく、また、確実に川俣 晶よりの返事を得られるものではないことにご注意ください。

このコンテンツへトラックバックするためのURL

http://mag.autumn.org/tb.aspx/20170310122959
サイトの表紙【技術雑記】の表紙【技術雑記】のコンテンツ全リスト 【技術雑記】の入手全リスト 【技術雑記】のRSS1.0形式の情報このサイトの全キーワードリスト 印刷用ページ

管理者: 川俣 晶連絡先

Powered by MagSite2 Version 0.25 (Alpha-Test) Copyright (c) 2004-2017 Pie Dey.Co.,Ltd.