ASP.NET Webフォーム

ASP.NET Webフォーム
原作者マイクロソフト
初回リリース2002 (2002年
オペレーティング·システムウィンドウズ
プラットフォーム.NET フレームワーク
タイプWebアプリケーションフレームワーク
Webサイトdotnet .microsoft .com /apps /aspnet /web-forms

ASP.NET Webフォームは、 Webアプリケーションフレームワークであり、 Microsoft ASP.NETテクノロジでサポートされている複数のプログラミングモデルの1つです。Webフォームアプリケーションは、 C#Visual Basicなど、共通言語ランタイムをサポートする任意のプログラミング言語で記述できます。Webフォームページの主な構成要素は、 HTMLマークアップのレンダリングとイベントへの応答を担う再利用可能なコンポーネントであるサーバーコントロールです。[ 1 ]ビューステートと呼ばれる技術は、通常はステートレスなHTTPリクエスト間でサーバーコントロールの状態を保持するために用いられます。[ 2 ]

Webフォームは、2002年にリリースされたオリジナルの.NET Framework 1.0(.NET Frameworkのバージョン履歴ASP.NETのバージョン履歴を参照)に、ASP.NETで利用可能な最初のプログラミングモデルとして含まれていました。新しいASP.NETコンポーネントとは異なり、WebフォームはASP.NET Coreではサポートされていません。[ 3 ]

特徴

ASP.NET Webページ(正式名称はWebフォーム)[ 4 ]は、 MVC導入以前、ASP.NETにおけるアプリケーション開発の主要な構成要素でした。[ 5 ] Webフォームには、Webアプリケーション形式とWebサイト形式の2つの基本的な手法があります。[ 6 ] Webアプリケーションは展開前にコンパイルする必要がありますが、Webサイトでは、ユーザーが事前にコンパイルすることなくファイルを直接サーバーにコピーできます。Webフォームは「.aspx」拡張子のファイルに含まれており、これらのファイルは通常、静的(XHTMLマークアップまたはコンポーネントマークアップを含んでいます。コンポーネントマークアップには、フレームワークまたはWebページで定義されたサーバー側Webコントロールとユーザーコントロールを含めることができます。例えば、テキストボックスコンポーネントは、HTML入力ボックスにレンダリングされるページ上で として定義できます。さらに、サーバー上で実行される動的コードは、 PHPJSPASPなどの他のWeb開発技術と同様に、ページ内のブロック内に配置できます。ASP.NET Framework 2.0では、Microsoftは新しいコードビハインドモデルを導入しました。これにより、静的テキストは.aspxページに残り、動的コードは.aspx.vb、.aspx.cs、または.aspx.fsファイル(使用するプログラミング言語によって異なります)に配置されるようになりました。[ 7 ]<asp:textboxid="myid"runat="server"><%--dynamiccode--%>

コードビハインドモデル

Microsoft は、動的プログラムコードを扱う際に、分離コードモデルの使用を推奨しています。分離コードモデルでは、このコードを別のファイルまたは専用のスクリプトタグに配置します。分離コードファイルは通常、「MyPage.aspx.cs」や「MyPage.aspx.vb」といった名前が付けられ、ページファイルはMyPage.aspxです(ページファイル (ASPX) と同じファイル名ですが、最後の拡張子はページの言語を表します)。Visual StudioなどのIDEではこの設定は自動的に行われますが、ユーザーは分離コードのページ名を変更できます。また、Web アプリケーション形式では、pagename.aspx.cs は pagename.designer.cs ファイルにリンクされた部分クラスです。デザイナー ファイルは、ASPX ページから自動生成されるファイルであり、これによりプログラマは、バージョン 2 より前の ASP.NET バージョンのように手動で宣言することなく、コード ビハインド ページから ASPX ページ内のコンポーネントを参照できます。[ 8 ]このスタイルのプログラミングでは、開発者は、ドキュメントの手順的なウォークスルーではなく、ページの読み込みやコントロールのクリックなどのさまざまなイベントに応答するコードを記述します。

ASP.NETのコードビハインドモデルは、開発者がプレゼンテーションとコンテンツの分離を念頭に置いてアプリケーションを構築することを推奨する点で、従来のASPからの脱却を特徴としています。理論的には、例えばWebデザイナーは、それを駆動するプログラミングコードに干渉する可能性を低減し、デザインマークアップに集中できるようになります。これは、モデル・ビュー・コントローラー(MVC)フレームワークにおけるコントローラーとビューの分離に似ています。

指令

ディレクティブ、ASP.NETがページを処理する方法に関する特別な指示です。[ 9 ]最も一般的なディレクティブは、ASP.NETページパーサーとコンパイラで使用される多くの属性を指定できます。 <%@Page%>

ユーザーコントロール

ユーザー コントロールは、ASP.NET でコントロールとして登録され使用されるページ セクションのセクションをカプセル化したものです。

カスタムコントロール

プログラマーはASP.NETアプリケーション用のカスタムコントロールを作成することもできます。ユーザーコントロールとは異なり、これらのコントロールにはASCXマークアップファイルが存在せず、すべてのコードがダイナミックリンクライブラリ(DLL)ファイルにコンパイルされます。このようなカスタムコントロールは、複数のWebアプリケーションやVisual Studio 2013プロジェクト で使用できます。

レンダリング技術

.NET は「visited complexes(訪問済み複合)」レンダリング手法を採用しています。コンパイル時に、テンプレート (.aspx) ファイルは初期化コードにコンパイルされ、このコードによって元のテンプレートを表すコントロールツリー(複合)が構築されます。リテラルテキストは Literal コントロールクラスのインスタンスに渡され、サーバーコントロールは特定のコントロールクラスのインスタンスによって表現されます。初期化コードはユーザー記述コード(通常は複数の部分クラスのアセンブリ)と結合され、ページ固有のクラスが生成されます。ページはコントロールツリーのルートとしても機能します。

ページへの実際のリクエストは、いくつかのステップを経て処理されます。まず、初期化ステップでは、ページクラスのインスタンスが作成され、初期化コードが実行されます。これにより初期のコントロールツリーが生成され、通常は以降のステップでページのメソッドによって操作されます。ツリー内の各ノードはクラスのインスタンスとして表現されるコントロールであるため、コードはツリー構造を変更したり、個々のノードのプロパティやメソッドを操作したりする可能性があります。最後に、レンダリングステップでは、ビジターを使用してツリー内のすべてのノードにアクセスし、各ノードにビジターのメソッドを使用してレンダリングするよう指示します。結果として得られるHTML出力はクライアントに送信されます。

リクエストが処理されると、ページクラスのインスタンスとコントロールツリー全体が破棄されます。これは、ページリクエスト/レスポンスサイクルごとに失われるクラスインスタンスメンバーに依存している初心者のASP.NETプログラマにとって、混乱の原因となります。

国家管理

ASP.NETアプリケーションはWebサーバーによってホストされ、ステートレスなHTTPプロトコルを使用してアクセスされます。そのため、アプリケーションがステートフルなインタラクションを使用する場合、独自に状態管理を実装する必要があります。ASP.NETは状態管理のための様々な機能を提供しています。概念的には、Microsoftは「状態」をGUIの状態として扱います。アプリケーションが「データ状態」を追跡する必要がある場合、問題が発生する可能性があります。例えば、リクエスト間で一時的な状態(遅延評価)になる可能性のある有限状態マシンや、初期化に長い時間がかかるマシンなどが挙げられます。認証を伴うASP.NETページでの状態管理は、Webスクレイピングを困難または不可能にする可能性があります。

応用

アプリケーションの状態は、共有ユーザー定義変数のコレクションによって保持されます。これらの変数は、Application_OnStartアプリケーションの最初のインスタンスの読み込み時にイベントが発生した際に設定・初期化され、最後のインスタンスが終了するまで利用可能です。アプリケーション状態変数には、Applicationsアプリケーション状態のラッパーを提供するコレクションを使用してアクセスします。アプリケーション状態変数は名前で識別されます。[ 10 ]アプリケーションは状態管理です。

セッション状態

サーバー側のセッション状態は、ユーザー定義のセッション変数のコレクションによって保持され、ユーザーセッション中は永続的に保持されます。これらの変数は、Sessionコレクションを使用してアクセスされ、各セッションインスタンスに固有のものです。これらの変数は、セッションが終了していなくても、一定時間操作が行われないと自動的に破棄されるように設定できます。クライアント側のユーザーセッションは、Cookie またはURL自体にセッションIDをエンコードすることで維持されます。[ 10 ]

ASP.NETは、サーバー側セッション変数の永続化に3つのモードをサポートしています。[ 10 ]

プロセス中モード
セッション変数はASP.NETプロセス内で維持されます。これは最も速い方法ですが、このモードではASP.NETプロセスがリサイクルまたはシャットダウンされると変数は破棄されます。
状態サーバーモード
ASP.NET は、状態変数を管理する別のWindows サービスを実行します。状態管理は ASP.NET プロセスの外部で行われ、ASP.NET エンジンは .NET Remoting を使用してデータにアクセスするため、ASPState は In-Process モードよりも遅くなります。このモードでは、ASP.NET アプリケーションを複数のサーバー間で負荷分散および拡張できます。状態管理サービスは ASP.NET とは独立して実行されるため、セッション変数は ASP.NET プロセスのシャットダウン後も保持されます。ただし、セッション状態サーバーは 1 つのインスタンスとして実行されるため、セッション状態にとって依然として単一障害点となります。セッション状態サービスは負荷分散できず、セッション変数に格納できる型には制限があります。
SQL Server モード
状態変数はデータベースに保存されるため、ASP.NETプロセスのシャットダウン後もセッション変数が保持されます。このモードの主な利点は、アプリケーションがサーバークラスター上で負荷分散を行い、サーバー間でセッションを共有できることです。これは、ASP.NETにおけるセッション状態管理方法の中で最も遅いものです。

ASP.NETセッション状態を使用すると、ユーザーがWebアプリケーション内のASP.NETページをナビゲートする際に、値を保存および取得できます。HTTPはステートレスなプロトコルです。つまり、Webサーバーはページに対する各HTTP要求を独立した要求として扱います。サーバーは、以前の要求で使用された変数値に関する知識を保持しません。ASP.NETセッション状態は、限られた時間内に同じブラウザから送信された要求をセッションとして識別し、そのセッションの期間中、変数値を保持する手段を提供します。既定では、ASP.NETセッション状態はすべてのASP.NETアプリケーションで有効になっています。

セッション状態の代替としては次のようなものがあります。

  • アプリケーション状態。ASP.NET アプリケーションのすべてのユーザーがアクセスできる変数が格納されます。
  • プロファイル プロパティ。ユーザーの値を期限切れにすることなくデータ ストアに保持します。
  • ASP.NET キャッシュは、すべての ASP.NET アプリケーションで使用できるメモリに値を保存します。
  • ページ内の値を保持するビュー ステート。
  • クッキー。
  • HTTP リクエストから利用できる HTML フォーム上のクエリ文字列とフィールド。

ビューステート

ビューステートとは、ASP.NET アプリケーションによって出力される HTML ページが Web フォームコントロールとウィジェットの状態を維持するために利用する、ページレベルの状態管理メカニズムのことです。コントロールの状態は、フォームが送信されるたびに と呼ばれる隠しフィールドでエンコードされ、サーバーに送信されます__VIEWSTATE。サーバーは変数を返すため、ページが再レンダリングされたときにコントロールは最後の状態でレンダリングされます。サーバー側では、処理によってコントロールの状態を変更する必要がある場合、アプリケーションはビューステートを変更できます。個々のコントロールの状態はサーバーでデコードされ、ViewStateコレクションを使用して ASP.NET ページで使用できるようになります。[ 11 ]

この主な用途は、ポストバックをまたいでフォーム情報を保持することです。ビューステートはデフォルトで有効になっており、通常、ポストバック中に実際に使用されるかどうかに関係なく、ページ上のすべてのコントロールのデータをシリアル化します。ただし、ビューステートはコントロールごと、ページごと、またはサーバー全体で無効化できるため、この動作は変更可能です(そして、変更すべきです)。

開発者は、ページやコントロールのビューステートに機密情報や個人情報を保存する際には注意が必要です。ビューステートデータを含むBase64文字列は簡単にデシリアライズできるためです。デフォルトでは、ビューステートは__VIEWSTATE値を暗号化しません。暗号化はサーバー全体(およびサーバー固有)で有効化できるため、一定レベルのセキュリティを維持できます。[ 12 ]

サーバー側キャッシュ

ASP.NETは、アプリケーション全体で共有され、様々なオブジェクトの保存にも使用できる「キャッシュ」オブジェクトを提供しています。「キャッシュ」オブジェクトは、指定された時間だけデータを保持します。

他の

ASP.NETでサポートされているその他の状態管理手段としては、Cookieキャッシュクエリ文字列などがあります。

テンプレートエンジン

ASP.NET が最初にリリースされたとき、テンプレート エンジンがありませんでした。.NET Framework はオブジェクト指向継承が可能であるため、多くの開発者は「」から継承する新しい基本クラスを定義し、そこに HTML をレンダリングするメソッドSystem.Web.UI.Pageを記述し、アプリケーションのページがこの新しいクラスを継承するようにしていました。これにより、サイト全体で共通要素を再利用できますが、複雑さが増し、ソース コードマークアップが混在することになります。さらに、この方法はアプリケーションを実行して視覚的にテストすることしかできず、設計時にはテストできません。他の開発者は、インクルード ファイルなどのトリックを使用して、すべてのページに同じナビゲーションやその他の要素を実装するのを避けてきました。

ASP.NET 2.0では、テンプレートベースのページ開発を可能にするマスターページの概念が導入されました。Webアプリケーションは1つ以上のマスターページを持つことができ、ASP.NET 2.0以降ではマスターページをネストすることが可能になりました。[ 13 ]マスターテンプレートには、動的コンテンツを配置する場所を示すContentPlaceHoldersと呼ばれるプレースホルダーコントロールがあり、子ページ間で共有される HTMLJavaScriptも配置されます。

子ページはContentPlaceHolderコントロールを使用します。これらのコントロールは、コンテンツページが生成するマスターページのプレースホルダーにマッピングする必要があります。ページの残りの部分は、ワードプロセッサ差し込み印刷のように、マスターページの共有部分によって定義されます。コンテンツページ内のすべてのマークアップコントロールとサーバーコントロールは、ContentPlaceHolderコントロール内に配置する必要があります。

コンテンツ ページが要求されると、ASP.NET はコンテンツ ページの出力をマスター ページの出力と結合し、その出力をユーザーに送信します。

マスターページはコンテンツページから完全にアクセス可能です。つまり、コンテンツページからヘッダーの操作、タイトルの変更、キャッシュの設定などを行うことができます。マスターページがパブリックプロパティやメソッド(著作権表示の設定など)を公開している場合、コンテンツページでもこれらを使用できます。

その他のファイル

ASP.NET のさまざまなバージョンに関連付けられている その他のファイル拡張子は次のとおりです。

拡大バージョンで導入説明
アサックス1.0これはグローバルアプリケーションファイルです。このファイルを使用して、グローバル変数(Webアプリケーション内の任意のWebページからアクセスできる変数)を定義できます。これは主に、アプリケーションとセッションオブジェクトに関連するアプリケーション全体のイベントを定義するために使用されます。Global.asax、アプリケーションレベルのロジックに使用されます[ 14 ]
ascx1.0ユーザーコントロール、ユーザーコントロールファイルロジックに使用される[ 15 ]
アシュックス1.0カスタムHTTP ハンドラーにはユーザー インターフェイスがありません。
asmx1.0Web サービスページ。バージョン 2.0 以降では、asmx ファイルのコード ビハインド ページが app_code フォルダーに配置されます。
aspx1.0Web コントロール、プレゼンテーション、ビジネス ロジックを含めることができる ASP.NET Web フォーム ページ。http ://msdn.microsoft.com/en-us/library/2wawkw1c.aspx
1.0web.configでtrace.axdを有効にすると、アプリケーションレベルのトレースが出力されます。また、特別なwebresource.axdハンドラにも使用されます。これにより、コントロール/コンポーネント開発者は、画像、スクリプト、CSSなどを含むコンポーネント/コントロールを1つのファイル(「アセンブリ」)にパッケージ化して展開できます。
ブラウザ2.0XML形式で保存されるブラウザ機能ファイル。バージョン2.0で導入されました。ASP.NET 2には、一般的なWebブラウザをサポートするために、これらのファイルが多数デフォルトで含まれています。これらのファイルによって、どのブラウザがどのような機能を持っているかが指定されるため、ASP.NET 2はそれに応じて出力を自動的にカスタマイズおよび最適化できます。W3C Validatorなどに対応する特別な.browserファイルは無料でダウンロードでき、標準に準拠したページを標準に準拠したものとして適切に表示できます。ASP.NET 1.xでは machine.configにあり、 web.configで上書き可能だった、使いにくいBrowserCapsセクションを置き換えます。
設定1.0web.config は、特定の Web アプリケーションにおいて、この拡張子をデフォルトで使用する唯一のファイルです(machine.config も同様に Web サーバー全体とサーバー上のすべてのアプリケーションに影響します)。ただし、ASP.NET には、他の構成ファイルを作成および使用する機能も用意されています。これらのファイルはXML形式で保存されます。
cs/vb/fs1.0コードファイル(csはC#、vbはVisual Basic、fsはF#を示します)。コードビハインドファイル(上記参照)は、主に2つの最も一般的な言語に対応する拡張子「.aspx.cs」または「.aspx.vb」を持ちます。その他のコードファイル(多くの場合、共通の「ライブラリ」クラスを含む)も、Webフォルダ内にcs/vb拡張子で存在する場合があります。ASP.NET 2では、これらのファイルはApp_Codeフォルダ内に配置する必要があります。これらのファイルは動的にコンパイルされ、アプリケーション全体で利用できるようになります。
cshtml4.1ビュー ( Razor構文を使用した C# と HTML の混合)
dbml3.5LINQ to SQLデータクラスファイル
エドエムエックス3.5ADO.NET エンティティ フレームワークモデル
マスター2.0マスターページファイル。デフォルトのファイル名はMaster1.masterです。
resx1.0国際化とローカリゼーションのためのリソースファイル。リソースファイルは、グローバル(メッセージなど)またはローカル(1つの aspx または ascx ファイルに固有のもの)にすることができます。
サイトマップ2.0サイトマップ設定ファイル。デフォルトのファイル名はweb.sitemapです。
2.0テーマスキンのファイル。
サービス3.0Windows Communication Foundationサービス ファイル
vbhtml4.1ビュー ( Razor構文を使用した VB と HTML の混合)

ディレクトリ構造

一般的に、ASP.NETのディレクトリ構造は開発者の好みによって決定できます。いくつかの予約済みディレクトリ名を除けば、サイトは任意の数のディレクトリにまたがることができます。この構造は通常、URLに直接反映されます。ASP.NETは処理中の任意の時点でリクエストをインターセプトする手段を提供していますが、開発者はリクエストを中央アプリケーションやフロントコントローラーに集約する必要はありません。

特別なディレクトリ名(ASP.NET 2.0以降)は次のとおりです。[ 16 ]

アプリコード
これは「生のコード」ディレクトリです。ASP.NETサーバーは、このフォルダ内のファイル(およびサブディレクトリ)を、サイトのすべてのページのコードからアクセス可能なアセンブリに自動的にコンパイルします。App_Codeは通常、データアクセス抽象化コード、モデルコード、ビジネスコードに使用されます。また、サイト固有のHTTPハンドラーやモジュール、Webサービスの実装もこのディレクトリに格納されます。開発者はApp_Codeを使用する代わりに、プリコンパイル済みコードを含む別のアセンブリを提供することもできます。
アプリデータ
App_Data ASP.NETディレクトリは、ASP.NETウェブサイトで使用されるすべてのデータベースのデフォルトディレクトリです。これらのデータベースには、Access(mdb)ファイルやSQL Server(mdf)ファイルが含まれる場合があります。App_Dataは、ASP.NETウェブアプリケーションに対して書き込みアクセスが有効になっている唯一のディレクトリです。[ 17 ]
アプリ_グローバルリソース
サイトのすべてのページで利用可能なローカライズされたリソースを含む resx ファイルを保持します。ASP.NET 開発者は通常、複数のページで使用されるローカライズされたメッセージなどをここに保存します。
アプリのローカルリソース
例えば、CheckOut.aspx.fr-FR.resxというファイルには、CheckOut.aspxページのフランス語版のローカライズされたリソースが格納されています。UIカルチャがフランス語に設定されている場合、ASP.NETはこのファイルを自動的に検出し、ローカライズに使用します。
アプリ_オフライン.htm
アプリケーション要求に対してファイルの内容を返すことでアプリケーションを無効にするファイル (ディレクトリではありません)。
アプリテーマ
テーマに関連するファイルを保持するフォルダーを追加します。テーマは、Web サイト全体で一貫した外観を確保し、必要に応じて Web サイトの外観を簡単に変更できるようにする新しい ASP.NET 機能です。
アプリ_Web参照
サイト内で使用されるWeb サービスへの参照用の検出ファイルとWSDLファイルを保持します。
ビン
アプリケーションで参照するコントロール、コンポーネント、その他のコードのコンパイル済みコード(.dllファイル)が含まれています。Bin フォルダ内のコードで表されるクラスは、アプリケーションで自動的に参照されます。

パフォーマンス

ASP.NETは、サーバー側コードを初めて使用するときにWebサーバー上の1つ以上のDLLファイルにコンパイルすることで、他のスクリプトベースのテクノロジ(Classic ASPを含む)よりもパフォーマンス上の利点を目指しています。これらのdllファイルまたはアセンブリには、共通言語ランタイム内で実行するためのMicrosoft中間言語(MSIL)が含まれています。これにより、純粋なスクリプト言語よりもパフォーマンスが向上し、Pythonで使用されるアプローチに似ており、JavaServer Pagesとも似ています。[ 18 ]このコンパイルは、ページが初めて要求されたときに自動的に行われます(つまり、開発者はページごとに別のコンパイル手順を実行する必要はありません)。

この機能は、スクリプト言語による開発の容易さと、コンパイル済みバイナリによるパフォーマンス上の利点を両立させます。ただし、コンパイルにより、新しく編集されたページがWebサーバーから最初に要求された際に、ユーザーにはわずかな遅延が発生する可能性があります。ただし、要求されたページがさらに更新されない限り、遅延は発生しません。

ASPXファイルおよびその他のリソースファイルは、インターネット インフォメーション サービスサーバー(または互換性のある他のASP.NETサーバー。詳細は後述の「その他の実装」を参照)上の仮想ホストに配置されます。クライアントが初めてページを要求すると、.NET Frameworkはファイルを解析して.NETアセンブリにコンパイルし、応答を送信します。以降の要求はDLLファイルから処理されます。デフォルトでは、ASP.NETは最初の要求時にサイト全体を1000ファイル単位でバッチコンパイルします。コンパイルの遅延が問題の原因となっている場合は、バッチサイズまたはコンパイル戦略を調整する必要があるかもしれません。

開発者は、Microsoft Visual Studio を使用して「コードビハインド」ファイルをデプロイ前にプリコンパイルすることもできます。これにより、実稼働環境でのジャストインタイムコンパイルが不要になります。 [ 19 ]これにより、Web サーバー上にソースコードを置く必要がなくなります。また、プリコンパイルテキストもサポートされています。

ASP.NETとClassic ASPの比較

ASP.NET WebFormsは、Windowsユーザーインターフェイスに似たコントロールで構成されたページを構築できるため、開発者のWindowsアプリケーション開発からWeb開発への移行を簡素化します。ボタンラベルなどのWebコントロールは、Windowsの対応するコントロールとほぼ同じように機能します。コードでプロパティを割り当てたり、イベントに応答したりできます。コントロールは自身をレンダリングする方法を認識しています。Windowsコントロールは画面に自身を描画しますが、WebコントロールはHTMLJavaScriptのセグメントを生成し、エンドユーザーのブラウザに送信されるページの一部を形成します。

ASP.NET WebFormsは、ASPやPHPといった従来のWebスクリプト環境ではなく、イベント駆動型のGUIモデルを用いたアプリケーション開発をプログラマーに推奨します。このフレームワークは、JavaScriptなどの既存の技術と「 ViewState 」などの内部コンポーネントを組み合わせることで、本質的にステートレスなWeb環境に永続的な(リクエスト間の)状態をもたらします。

Classic ASPと比較したその他の違いは次のとおりです。

  • コンパイルされたコードでは、開発段階でより多くの設計時エラーが捕捉され、アプリケーションの実行速度が向上します。
  • try-catch ブロックを使用した例外処理を活用することで、実行時エラー処理が大幅に改善されました。
  • コントロールやイベントなどの Microsoft Windows アプリケーションに類似したメタファー。
  • 豊富なコントロールとクラスライブラリ、そしてユーザー定義コントロールにより、アプリケーションを迅速に構築できます。これらのコントロールのレイアウトは、ほとんどのエディターで視覚的に行うことができるため、ページ上でのレイアウトも容易です。
  • ASP.NET は、.NET共通言語ランタイムの多言語機能を使用して、Web ページを VB.NET、C#、F#、Delphi.NET などでコーディングできるようにします。
  • パフォーマンスを向上させるためにページ全体または一部をキャッシュする機能。
  • コード ビハインド開発モデルを使用してビジネス ロジックをプレゼンテーションから分離する機能。
  • ページやコントロールのプログラミングに真のオブジェクト指向設計を使用する能力
  • ASP.NET アプリケーションがメモリ リークを起こした場合、ASP.NET ランタイムはエラーを起こしているアプリケーションをホストしている AppDomain をアンロードし、新しい AppDomain にアプリケーションを再ロードします。
  • ASP.NET のセッション状態は、 Microsoft SQL Serverデータベースに保存するか、Web サーバーと同じマシンまたは別のマシンで実行される別のプロセスに保存できます。これにより、Web サーバーがリセットされたり、ASP.NET ワーカープロセスがリサイクルされたりしても、セッション値が失われることはありません。
  • ASP.NET 2.0より前のバージョンは、標準への準拠が不十分であると批判されていました。クライアントブラウザに送信される生成されたHTMLとJavaScriptは、必ずしもW3C / ECMA標準に準拠しているとは限りませんでした。さらに、フレームワークのブラウザ検出機能は、Microsoft独自のInternet Explorer以外のWebブラウザを誤って「ダウンレベル」と認識し、一部の機能が削除されたHTML/JavaScript、あるいは機能不全に陥ったHTML/JavaScriptをクライアントに返すことがありました。しかし、バージョン2.0では、すべてのコントロールがサイト構成に応じて、有効なHTML 4.0、XHTML 1.0(デフォルト)、またはXHTML 1.1出力を生成します。標準準拠のWebブラウザの検出はより堅牢になり、カスケーディングスタイルシートのサポートもより広範囲になりました。
  • Webサーバーコントロール:ASP.NET WebFormsによって導入された、WebフォームのUIを提供するためのコントロールです。これらのコントロールは状態管理型であり、WYSIWYGコントロールです。

<%@ Page Language = "C#" %> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" " http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd " > < script runat= " server" > protected void Page_Load ( object sender , EventArgs e ) { Label1.Text = DateTime.Now.ToLongDateString ( ) ; } </script> <html xmlns= "http://www.w3.org/1999/xhtml" > <head runat= " server" > <title>サンプルページ</title> </head> <body> <form id= "form1" runat= "server" > <div>現在の時刻は: <asp:Label runat= "server" id= "Label1" /> </div> </form> </body> </html>

[ 20 ]

参考文献

引用

  1. ^ 「Webフォームとは」 . docs.microsoft.com . 2023年6月15日.
  2. ^ 「 ASP.NETビューステートの概要」。msdn.microsoft.com。2014年 12 月 4 日。
  3. ^ 「ASP.NET と ASP.NET Core のどちらかを選択する」 . docs.microsoft.com . 2024 年 4 月 10 日。
  4. ^スタッフ (2001年11月). 「ASP.NETとWebフォームの概要」 . Microsoft . 2011年6月5日閲覧。
  5. ^ (マクドナルド & シュプスタ 2005、p. 63)
  6. ^ 「Visual Studio における Web アプリケーション プロジェクトと Web サイト プロジェクト」。2013 年 8 月 26 日。
  7. ^ 「コードビハインドとコードインライン」。Microsoft .NET Framework。Microsoft 2010年11月11日時点のオリジナルよりアーカイブ2010年11月22日閲覧
  8. ^ 「aspx.designer.csはどのように機能しますか?」StackOverflow . 2015年9月10日。
  9. ^ 「ASP.NET Webページ構文の概要」 . Microsoft .NET Framework . Microsoft . 2010年11月22日閲覧
  10. ^ a b c「INFO: ASP.NET 状態管理の概要」 。 2007年10月23日閲覧
  11. ^ 「ASP.NETのViewState」2007年10月14日時点のオリジナルよりアーカイブ2007年10月23日閲覧。
  12. ^ 「ASP.NET での Viewstate の暗号化」 。2009年 7 月 19 日閲覧
  13. ^ 「ASP.NET マスター ページ」 . microsoft.com . Microsoft. 2014 年 12 月 4 日。
  14. ^ 「Global.asax 構文」 . microsoft.com . Microsoft.
  15. ^ 「.ascx ユーザー コントロールを再頒布可能なカスタム コントロールに変換する」 . microsoft.com . Microsoft. 2011 年 6 月 24 日。
  16. ^ 「ASP.NET Web プロジェクトのフォルダー構造」 . microsoft.com . Microsoft. 2014 年 12 月 4 日。
  17. ^ 「ASP.NET ディレクトリ構造」 . aspnet4.com . 2011年10月27日時点のオリジナルよりアーカイブ2018年6月16日閲覧。
  18. ^ (マクドナルド & シュプスタ 2005、7–8 ページ)
  19. ^ 「ASP.NET Web サイト プロジェクトのプリコンパイルの概要: プリコンパイルの実行」。Microsoft Developer Network。2014年 12 月 4 日。20161 月 13 日に閲覧
  20. GitHubpygments /tests/examplefiles/aspx-cs/aspx-cs_example.aspx

出典