Pages)で小さなサイトを作ってみました。Pagesを推奨しているようですが、実際に使ってみてMVCから乗り換えるに値するものなのか判断できればいいなーと思っています。Pagesのプロジェクトと比較対象のMVCプロジェクトは以下のようなかんじです。Coreバージョンの違いによる問題をPagesの問題と勘違いしている可能性があります。100+メリットViewModelクラスを定義しなくていいMVCではページごとにViewModelクラスをいちいち作るのが面倒くさいです。ViewDataやViewBagもいまいちです。Pagesではcshtml.csに定義されるページ専用コントローラー兼ビューモデルであるPageModelクラスが自動で作成されます。これをそのままViewModelにすることができます。ビューに渡したいデータがあればPageModelクラスに新しいプロパティを追加してそれに値をセットすればビューから参照できます。Pagesはコントローラーをビューモデルと共用しているわけです。これは単一のビューに限定されたクラスだからできることだと思いますし、実際便利だと思いました。MVCではコントローラークラスは複数ページ共用なのでこれをやれないんですね。Pagesではページ毎に1ファイルというかんじになるので、フォルダ構造がそのままルーティング構造になります。PagesではこのURLならこのファイルだなとすぐ分かります。Pagesでは表現できないため、MVCで作ることになります。Pagesに移行できるわけではないです。Pagesには独自のルーティングルールがあります。リンクもUrl.ActionではなくUrl.Pageで作ります。Pagesにするのであれば問題ありませんが、MVCと混在することを前提とした場合、ルーティングルールが2つあるというのはちょっと負担になります。Pagesでは1ページ毎に専用コントローラーになるので、MVCのように複数アクションでメソッドを共用したり、部分ビューを共用することがやりにくいです。PagesではSharedフォルダに置くことになります。Sharedフォルダが混雑しそうです。メソッド場合は、PageModelの継承クラスを定義したりすることになるのでしょうか。Studioが不安定デバッグ実行とデバッグなし実行を切り替えたり、ビルドを実行したりなどのタイミングで、ブラウザ更新をかけるとページが表示されない状態になります。MVCではそんなことありませんでした。Studioが不安定2使用していると、変数名やクラス名を変更したりなどするタイミングでVSが応答なしになることがあります。復帰までに1分くらいかかります。1度この状態になると頻繁にこの現象が発生するのでVSを再起動しています。すると数時間は持ちます。アナライザが何やらしているような感じです。MVCではそんなことありませんでした。Pagesでは*.cshtmlだけの変更でも2秒ほどかかります。PageModelもコンパイルしているのでしょうか。*.cshtml.csやその他の*.csの変更によるコンパイル時間はMVCより早いように感じます。Pagesは関連するページだけコンパイルしている感じです。間違っていたらすみません。Pagesに乗り換えることは出来ないビューへの値渡しを気軽にできるのはよかった現状、VSが不安定すぎて使えない。Pagesに依存する問題かどうかは分からないが)*.cshtmlの変更だけでコンパイルするのはやめてほしい。Pagesの第一印象Tweet関連記事2015-06-30よく使うRazor記述パターン自分用メモ。はてなブログProASP.NET、PHPを中心に書いています。注目記事はてなブログをはじめよう!sumi2さんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。