私は最初のASP.NetMVCアプリケーションに取り組んでいます。Razorビューを使用しており、MVCバージョンは3です。データベースからモデルのデータを生の形式で取得しています。次に、文字列を連結したり、いくつかのlinqクエリを使用して日付列をフォーマットしたりするなどの処理を行います。モデルクラスにすでにあるデータのすべて。
このコードの実行はすべてサーバー上で行われているのだろうか。この負担をサーバーからクライアントマシンに移動したいのですが、この生データをビューに渡してから、ビュー内のコードを記述して、このループ処理やフォーマットなどを実行したいと思います。
これが先に進むための良いアプローチであるかどうか、そしてこれが本当に私のサーバーからいくらかの負担を解放するかどうかを確認したいだけです。
ありがとう
ビューに書き込まれるC＃またはVBは、クライアント側ではありません。それはまだサーバー側です。これは、クライアントに渡される前にHTMLのレンダリングを操作するために使用されます。
すべての生データを渡してから、JavaScriptで処理する必要があります。
アプリのパフォーマンスは各クライアントマシンに依存するため、2人のユーザー間で一貫性がありません。結果として、メンテナンスには注意が必要です。
長い話を短くするために、私はそれをお勧めしません。サーバーは、負荷を処理するように設計されている可能性があります。この種のものに適した場所です。
また、サーバー側とクライアント側のコード実行の関係についても読みました。単にMVCを実行することは良いスタートです。Webフォームを使用するよりも、Webがどのように機能するかを自然に教えてくれます。
これは時期尚早の最適化である可能性があります。文字列の連結やフォーマットなどの単純な処理を実行するサーバーが停止するかどうかは疑問です。
パフォーマンスの問題が発生した場合にのみ、これに焦点を当てることをお勧めします。そうでなければ、努力する価値はありません。
MVCのビューとブラウザーのHTMLを混同したと思います。ビューには任意のC＃コードを含めることができますが、ブラウザーには含めることができません。ビューでビジネスロジックを実行することについて質問がある場合は、さらに読んでください。
MVCを使用すると、あらゆる種類のビュー（モバイル、デスクトップ、Webアプリ）をコントローラーにプラグインできます。したがって、viewはビジネスロジックを実行しないでください。そうしないと、ビジネスロジックが複製されることになります。
このリンクは、MVCの理解に役立ちます。
ビューでのデータの書式設定はまったく問題ではありませんが、ビューでビジネスロジックの実装を開始すると、それが問題になります（ビューでlinqを使用することで意味したことだと思います）。
たとえば、ビュー内で、モデルエンティティでlinqを使用してコレクションをループし、HTMLテーブルを作成することはまったく問題ありません。実際、ViewModelはViewに緊密に結合する必要があります。
[ここでは哲学的にならないように一生懸命努力していますが:)]結局、どのアーキテクチャを使用しても、箱から出して考えることを制限しないでください。ほとんどすべてのプロジェクトは複数のパターンを使用しており、ほとんどの（優れた）開発者は無意識のうちにパターンを実装することでビジネス上の問題を解決します。:)