Serviceを読んで理解し、同意したものとみなします。775件-1最近asp.netプロジェクトに中途参加したのですがどうも基本的な処理でいろいろと問題が発生しています。フレームワークを正しく使っていないのか、さもなくばMSが相変わらずクソなのか真実を知りたく達人のお知恵を授かりたいと思います。以下現在自分が気になっている点です。MVC現行MVCモデルになっておらず、各々別個のページ(.aspx)にアクセスしている。現行ページ遷移はServer.Transferで行っている。従ってブラウザが認識するのは”前ページ”であるため(か)いろいろ”不都合”が生じ妙なパッチを当ててしのぐ必要がある。複数のウインドウで異なるログインでの使用はアプリケーション側ではできない。「すでにログインしているサービスに、別なウインドウから別なアカウントで同時にログインして使いたい」というのはごくありふれたニーズだが、セッションでシンプルに管理していうとストレートに対応できない。そもそも.NETでは”ログイン管理”はどうするのが正しいのか?ちなみに本プロジェクトは規模も歴史も長大なので、今更基本構造をどうこうはできませんが後学と好奇心のため、お手すきの達人がおられましたらご教授いただければ幸いです。そこらへんを簡潔明快にまとめた記事があればご紹介ください。票3現行MVCモデルになっておらず、各々別個のページ(.aspx)にアクセスしている。Formsというフレームワークでこれは10年近く前の技術になります。MVCが開発段階にあります。現行ページ遷移はServer.Transferで行っている。従ってブラウザが認識するのは”前ページ”であるため(か)いろいろ”不都合”が生じ妙なパッチを当ててしのぐ必要がある。そもそも.NETでは”ページ遷移”はどうするのが正しいのか?これはResponse.Redirectを使用すべきです。複数のウインドウで異なるログインでの使用はアプリケーション側ではできない。Cookieの仕様に基づいたWebアプリケーションではごく一般的な動作だと思います。複数の状態を管理したいのであればクエリー文字列などでパラメーターを明示的に渡してやる必要があるかと思います。個の銅バッジありがとうございます。Response.Redirectだと通信がダブりますが、これは”ロス”とは理解されないのでしょうか?セッションを”Cookieで”管理しているのは.netの勝手です。アプリケーションサイドとして”セッション”という機能に求めるものは、暫定的継続的なデータの共有でしょう。確かにリダイレクトのラウンドトリップは発生しますが、サーバー側の負荷はさほど変化しませんし、ユーザーに対しても表示しているURLと内容が一致するというメリットもあります。/>というURLベースの実装も用意されていますがお勧めはしません。/>を出力して認証で利用するなどした方がよっぽど影響範囲が小さいと思います。いうのはごくありふれたニーズだが、セッションでシンプルに管理していうとストレートに対応できない。質問とズレるのでオフトピですが...1つのブラウザでセッションが1つきりと言うのは一般的ですので、別アカウントで開きたいというニーズには、Chromeのユーザプロファイルを使い分けることで対応してもらってます。2002からとなり、当時はまだAJAXという概念が存在していませんでした。2008からとなります。プロジェクトの歴史が長大とのことですが、2008年以前に設計されたものであれば仕方がないかと思います。古いままを維持するか、AJAXやMVCなど順次新しい技術を取り入れていくかはプロジェクト次第かと思います。メソッドで提供されるリソースを表示する権限が与えられているかどうかを確認しません。とあるように、権限の確認が行われないなど特殊な動作をしますからページ遷移に常用するのはお勧めできません。href>によるページ遷移が可能ですので特殊な記述をすべきではありません。ログイン管理あるいはマルチセッション他の方々も言及されていますが、Webとしては一般的な動作です。逆に「すでにログインしているサービスに、別なウインドウから別なアカウントで同時にログインして使いたい」というのはごくありふれたニーズに応えているWebサイト等ありましたら挙げてみてください。具体例が見つからないようでしたら「ごくありふれたニーズ」という認識を改めることをお勧めします。個人的にはフレームワークを正しく使っていないに1票投じます。個の銅バッジありがとうございます。MVC:”ajax”という言葉こそなかったものの、1996年頃にも”バックグラウンドで非同期通信でクライアントを更新をする”というアプローチはありました。MVCというモデルもやはりすでにその頃にもありました。それがどう実装されているか気にせずアプリケーションを開発できるのが理想的なフレームワークです。MSのような業界のリーディングカンパニーにはそういう矜持で望んでもらわねばなりません。1:16ページ遷移:リクエストに対しサーバサイドで処理した結果、遷移先が決定されるというケースは少なくありません。アプリケーションシステムでは「エラー対応」が必須ですから、クライアント側で”遷移先”を予め特定することはできないのが基本です、ですからサーバサイドでページ遷移(というかクライント側にしかるべき”View”を送出)する仕組みがスタンダードで提供されていると考えるのがアプリケーション開発者としては当然です。それがTransferでもRedirectでも何かしら不完全なので、”本来の使い方”がないのだろうかという疑問です。1:31ログイン管理あるいはマルチセッション:例えばgmailです。(?)と付けたのはその語句が概念的に正しいのか確信がなかったからですが、すなわちセッション=”クライアントとの暫定的継続的なデータ共有”をアプリケーションサイドで任意に”マルチ”にする機能です。当プロジェクトでの失敗ということであれば、.netのセッションではそれができないのに、ログイン管理を”素のまま”のセッションで実装したことになりますが。ちなみに”セッション”に求める本来の機能が”cookieだけによって”実装されているのはフレームワークの勝手です。この”ありふれたニーズ”を見越していれば、例えばport(とその開き方)による管理もオプションで用意されているべきです。|回答スタック・オーバーフローに参加してくれて、ありがとうございます!質問の回答を共有してください。回答を説明し、自分の検討結果も共有してください。意見を述べること(意見を述べるなら、参照リソース、自分の経験で意見をサポートしてください)さらにサポートが必要な場合このヘルプを参考してください。“回答を投稿”をクリックすることで利用規約、プライバシーポリシー、及びクッキーポリシーに同意したものとみなされます。タグが付いた他の質問を参照するか、自分で質問をする。HtmlTableで行データが正しく取得できない。質問のフィードこのRSSフィードを購読するには、このURLをコピーしてRSSリーダーに貼り付けてください。