ASPアプリケーションの成功は通常、アーキテクチャと設計のトレードオフに依存します。幅広いASPテクノロジーと現在のアプリケーションの固有の複雑さを考慮すると、このトレードオフは非常に困難です。間違った新しいテクノロジーチャネルでのASPの原則と使用に関する簡単な紹介を次に示します。
命名規則を確立し、ディレクトリ構造を標準化することで、ASPアプリケーションの読みやすさと保守性を大幅に向上させることができます。現在、ASPアプリケーションには正式な基準はありませんが、多くの開発者はいくつかの共通の方法を確立しています。ここで、私はあなたともっと一般的な方法を共有します。
ASPテクノロジーはスクリプトエンジンに依存して機能し、スクリプトにはタイプが厳しくないという性質があるため、命名規則もあいまいです。非常に厳格なタイプの言語では、実際のタイプに従って変数が宣言されます。 ASPテクノロジーを使用する場合、変数は通常、実際のデータ型ではなく、変数を処理する方法でASPコードで宣言されます。たとえば、「Visual Basic（R）Scripting Edition（VBScript）」を使用する場合、すべてのVBScript変数はバリアントですが、vSuccessの代わりにSuccess Flag（boleanのb）として宣言します（バリアントの場合はv）。
次の表には、いくつかの一般的な命名規則があります。
変数プレフィックス：
| プレフィックス | 使用される変数 | 可変例 |
|---|---|---|
| bまたはbln | ブール | bsuccess |
| cまたはcur | 通貨 | カムカウント |
| dまたはdbl | ダブル | dblquantity |
| dtまたはdat | 日時 | dtdate |
| fまたはflt | フロート | フラチオ |
| lまたはlng | 長さ | lmilliseconds |
| 私またはint | 整数 | icounter |
| sまたはstr | 弦 | スナム |
| aまたはarr | 配列 | ausers（） |
| oまたはobj | comオブジェクト | オピペリン |
データベースオブジェクトの変数プレフィックス：
| プレフィックス | 使用される変数 | 可変例 |
|---|---|---|
| CNN | 繋がり | cnnpubs |
| RST | レコードセット | rsstauthors |
| CMD | 指示 | cmdemployee |
| fld | 分野 | fldlastname |
範囲とプレフィックスの使用：
| プレフィックス | 説明します |
|---|---|
| G_ | Global.asaで作成されました。 |
| m_ | ASPページまたはインクルードファイルの場合、それはローカルです。 |
| （プレフィックスなし） | 非静的変数、プレフィックスはプロセスにローカルです |
ナレッジベース（KB）の投稿「Q110264情報：Visual BasicのためのMicrosoft Consulting Servicesの命名規則」（英語）は、命名規則に関する洞察を提供します。
可能な場合はディレクトリ構造を使用して、さまざまなアプリケーションコンポーネントに一貫した場所を提供します。アプリケーションの実際のディレクトリ構造はもちろんあなた次第ですが、通常、画像、ドキュメント、ファイル、コンポーネントを別々のディレクトリに配置することです。以下は、単純なASPアプリケーションディレクトリ構造の例です。
ディレクトリ構造の例：
/simpleaspapp /docs /images /include
優れたディレクトリ構造により、NTFSアクセス許可を選択的に適用できます。 ASPアプリケーション内から相対パスを使用することもできます。たとえば、次のコードを使用して、simpleaspappディレクトリにあるdefault.aspページのinclude directoryにinclude file top.aspを参照できます。
./includes/top.asp
インクルードファイルの拡張子は.aspであり、.incではないことに注意してください。これは、セキュリティ上の理由で行われ、.asp拡張（.incではなく）を使用し、視覚的なInterdev（r）で色エンコードを有効にします。
構造化されたASPアプリケーションに関する他のヒントやヒントについては、記事「ASP Conventions」（英語）を参照してください。
ASPはサービスの下で実行されます。 ASPアプリケーションを設計するとき、デスクトップアプリケーションで遭遇しないセキュリティ環境とスレッド化の問題に直ちに直面します。デスクトップ環境では、インタラクティブなユーザーが通常処理され、現在のデスクトップシステムにアクセスできるように、単一のスレッド実行実行のみが実行されます。インターネット情報サービス（IIS）では、さまざまなユーザー環境の複数のクライアントスレッドがシミュレーションしてアプリケーションを呼び出し、アプリケーションは「システム」デスクトップに限定されます。
これはあなたにとって何を意味しますか？ IISの安全モードを学んでください。また、視覚的な基本IDEの下で何かが適切に実行できるからといって、ASPテクノロジーで安全に実行できるという意味ではありません。 Visual Basic IDEは、ランタイム環境を正確にシミュレートしません。一般的な設計エラーには、ASPテクノロジーのユーザーインターフェイスを必要とする.OCXコントロールの使用、スレッドに安全ではないコンポーネントを使用し、特別なユーザーコンテキストを必要とするコンポーネントを使用することが含まれます。避けるのが最も簡単な問題の1つは、アプリケーションからHKEY_CURRENT_USER（HKCU）レジストリキーにアクセスしようとすることです（たとえば、HKCUに依存するVisual BasicのGetSettingおよびSaveSetting関数を呼び出さないでください）。同様に、ユーザーがヒューマンコンピューターと対話する必要があるメッセージボックスやその他のダイアログボックスは表示されません。
次の記事は、ASPテクノロジーのセキュリティと検証の問題に関するかなり良い紹介書です。
ASPテクノロジーは、HTML出力を生成することにより、代表サービスを提供します。要するに、ユーザーインターフェイスを生成します。 ASP表現スクリプトからビジネスロジックを分離する必要があります。 COMコンポーネントを使用してASPコードからビジネスロジックを分離しなくても、少なくともビジネスロジックを関数に分離し、メンテナビリティ、読みやすさ、再利用性を向上させるファイルを含めます。また、トラブルシューティングや隔離の問題が必要なときに、モジュラー設計方法の利点を理解することもできます。
スクリプト内の関数とメソッドを呼び出すと、コードを台無しにしないようにし、ASPアプリケーションに構造を追加できます。次の例は、ASPコードからメソッド呼び出しにロジックを分離する方法を示しています。
lt;％main（）mybizmethod（）... sub main（）getdata（）displaydata（）end sub％>
この原則は、ASP機能を含む手法を使用する場合に適用できます。 Visual Basic WebClassを使用する際に、この原則を使用する方法の例を次に示します。
一般的な問題は、デスクトップシステムからサーバーへの移行です。デスクトップシステムの背景を持つ多くの開発者は、サーバーの問題やリソース共有について心配することはありません。従来のデスクトップアプリケーションでは、サーバーに接続することは時間のかかるプロセスです。ユーザーエクスペリエンスを改善するために、通常、リソースを早期に取得し、リソースのリリースを遅らせるために使用されます。たとえば、多くのアプリケーションは、実行時間を通じて常にデータベースに接続されます。
この方法は、従来のデスクトップアプリケーションで適切に機能します。その理由は、ユーザーの数が非常に明確で、制御しやすく、バックエンドとフロントエンドが密接に接続されているためです。ただし、現在のWebアプリケーションでは、限られたサーバーリソースがますます多くのユーザーに直面するため、このアプローチは実行可能ではなくなりました。アプリケーションがユーザーの増加に対処するには、可能な限り遅れてリソースを取得し、できるだけ早くリソースをリリースする必要があります。
共有は、このアプローチの有効性を高めるのに役立ちます。共有を通じて、複数のユーザーがリソースを共有でき、最小待ち時間とサーバーへの影響を最小限に抑えます。たとえば、データベースを使用する場合、ODBC接続共有とOLEDBリソース共有により、共有プールから接続を選択して、データベースへの接続のオーバーヘッドを最小限に抑えることができます。
ADOの共有の詳細については、「Microsoft Dataアクセスコンポーネントのプーリング」を参照してください。
HTTPプロトコルはステートレスですが、ASP開発者はしばしばASP機能に組み込まれた状態保持メカニズムを使用します。たとえば、ASPテクノロジーに組み込まれたアプリケーションオブジェクトを使用して、開発者によって保存されたリソースをアプリケーションのすべてのユーザーが共有できます。 ASPの組み込みセッションオブジェクトを使用することにより、開発者は1人のユーザーのみでリソースを保存します。
ASPテクノロジーのセッションオブジェクトに情報を保存することは、状態を維持するための非常に便利な方法であるように聞こえますが、このアプローチは高すぎるため、スケーラビリティに関する最大の制限要因の1つになります。アプリケーションのスケーラビリティは、基本的に、ユーザーの数が増えるにつれてパフォーマンスを維持し続ける能力です。各ユーザーについて、セッションオブジェクトは、セッションがタイムアウトまたは放棄される前にサーバーのリソースを消費します。セッションもサーバーに拘束され、Webクラスターを利用する能力を制限します。国家管理のために可能な限りASPセッションオブジェクトを使用しないでください。セッションをまったく使用していない場合は、Webアプリケーションのセッションステータスを無効にすることができます（IISドキュメントを参照）。それ以外の場合は、次のステートメントを使用して、各ページのセッションステータスを無効にできます。
<％@enablessessionState = false％>
いくつかの簡単なデータでは、 QueryString CookieまたはHidden Formドメインを使用して、ASPリクエスト間で状態を維持できます。次に、より複雑な情報のために、通常、データベースを使用することをお勧めします。一般的なアプローチは、一意の識別子を生成し、それを要求する各クライアントに送信し、隠されたフォームフィールドとして保存することです。以降のリクエストでは、この一意の識別子を使用して、データベース内のユーザーに関連するステータス情報を検索します。このアプローチは、より高いスケーラビリティとより簡潔で明確なコードを提供します。
クエリストリングクッキーと非表示のフォームフィールドの使用の詳細については、「Q175167 Howto：セッションなしの持続値」を参照してください。
ASPテクノロジーオブジェクトを作成するときは、選択できます
可能な例外は次のとおりです。ファイアウォールを介して電話をかけるときは、 server.createObjectの代わりにCreateObjectを呼び出す必要があります。詳細については、「Q193230 -PRB：server.createObjectがオブジェクトがファイアウォールの背後にあるときに失敗する」（英語）を参照してください。
エラー処理がすべてのASPアプリケーションに含まれていることを確認してください。また、有用な診断情報を提供してください。エラーメッセージがあまりにも説明的であると不平を言っている人に遭遇していません。エラーログに次の情報を含めてください。
ASPの下で実行されるため、この情報をファイルまたはNTのイベントログに書き込むことができます。また、アプリケーションエラーを診断するときに使用する重要なアプリケーションイベントを記録するアプリケーションイベントログを作成することもできます。
次の記事では、エラー処理手法に関する詳細情報を提供します。
ブラウザはそれをテストする正確な方法ではなく、アプリケーションの可能性のある使用のみを示すことができます。アプリケーションに特定のパフォーマンス目標を設定し、ストレステストのためにWebアプリケーションストレスツールなどのロードツールを使用してください。あなたの環境が何を受け入れることができるかを自分で決定する必要があります。ここに、テストプロセスを開始するのに役立つ一般的なガイドラインがあります。
テスト環境を実際の実行環境と一致させ、ファイアウォールでさえも例外ではありません。これは高価に聞こえますが、開発者がファイアウォールを考慮しないため、開発者が仕事を失うのを聞いたことがあります。
Webアプリケーションストレスツールを使用したASPアプリケーションのテストの詳細については、「私はそれを十分に強調できません - ASPアプリケーションをロードする」を参照してください。
分離で申請プロセスを保護すると、サーバーの安定性が大幅に向上する可能性があります。インターネットアプリケーションに関しては、分離を使用する結果は大きく異なる場合があります。1つはアプリケーションのクラッシュであり、もう1つはサーバーのクラッシュです。プライマリIISプロセス（inetinfo.exe）の保護は、通常、より高い優先リストにあります。これは、コンポーネントを使用する場合に特に顕著です。
主要なISSプロセスを保護するために一般的に使用される手法は、Webアプリケーションがそれぞれのメモリスペースで実行できるようにすることです。インターネットサービスマネージャーでは、各Webに対してこのオプションを設定できます。マーシャリングプロセスに圧倒されるシステムリソースは、パフォーマンスにわずかな影響を与えますが、アプリケーションへの保護効果はコストに見合う価値があります。 IIS 4.0では、アプリケーションを処理およびプロセス（OOP）内で実行できます。 OOPアプリケーションは、新しいmtx.exeインスタンスで実行されます。 IIS 5.0では、他の分離オプションを使用できます。分離レベルは、「低」（inetinfo.exeのインプロセスアプリケーション）、「中」（dllhost.exe共有インスタンス）、または「high」（dllhost.exeの非共有インスタンス）に設定できます。
独自のメモリスペースでWebアプリケーションを分離することに加えて、信頼できないコンポーネントを分離することもできます。信頼されていないコンポーネントは、通常、実際の環境でテスト時間に合格しないコンポーネントです。これらのコンポーネントは、サーバーパッケージで実行して、新しいdllhost.exeインスタンスで実行できるようにします。
一般的に言えば、パフォーマンスと保護の間に適度なアプローチを取りたい場合は、次の方法です。Webアプリケーションを「高」分離状態で実行し、ライブラリパッケージでコンポーネントを実行します。このアプローチは、プロセス間の最も強力な保護を提供しながら、マーシャル費用を最小限に抑えます。
詳細については、記事「プロセス分離によるサーバーの信頼性」を参照してください。
IIS 4.0の下では、ASPのデフォルトの共通グループは、各MTS管理プロセッサの10スレッドです。 IIS 5.0では、デフォルト値は20です。これは、各スレッドが複数のクライアントリクエストを処理できる潜在的に価値のあるリソースであることを意味します。また、大規模なデータベース呼び出しを行うなど、発生する可能性のあるブロック方法を避ける必要があります。これを行う仕事がある場合は、ASPアプリケーションがクライアントへの応答をすばやく返すことを妨げます。キューイング機能の使用を検討してください。たとえば、NT 4.0では、MSMQを使用できます。 Windows 2000では、キューに囲まれたコンポーネントを使用できます。
セッションにシングルスレッドアパート（STA）コンポーネントを保管しないという一般的な欠点の1つは、セッション範囲の視覚的な基本オブジェクトを埋めることです。ユーザーをスレッドにロックします。これは、スレッドごとにグループを共有する目的に反して実行されます。潜在的なユーザーは、他のユーザーの背後にブロックされ、コンポーネントを作成するスレッドが有効になるのを待っています。他の方法を使用して、各ページに基づいて作成および破壊できるステートレスコンポーネントを設計する必要があります。
クイックヒント： ASPスクリプトデバッグ機能がサーバー上で無効になっていることを確認してください（インターネットサービスマネージャーを使用）。 ASPスクリプトのデバッグが有効になっている場合、ASPの実行はスレッドにロックされます。
詳細については、次の記事を参照してください。
ASPアプリケーションを作成するには、かなりの範囲の知識が必要です。 ASPアプリケーションの課題の1つは、現在一般的なルールがないことです（これは楽しみの一部です）。別の問題は、多くの開発者がインターネット開発と接触する前にデスクトップシステム開発に従事していることです。 ASP開発の取り組みに上記のルールを適用することにより、費用のかかる間違いを回避し、かなり優れたASPアプリケーションを開発できることを期待しています。
JD Meierは、米国の東海岸で生まれ育ちました。 Horace Greeleyのアドバイスに従って、彼は開発者サポートエンジニアになり、MTSやASPテクノロジーなどのサーバー側コンポーネント、Windows DNAアプリケーションに焦点を当てました。
The New Technologyチャネルの編集者によって紹介されたコンテンツを通じて、誰もが特定の理解を持っていると思います。より多くの技術的なコンテンツを知りたい場合は、引き続き新しいテクノロジーチャネルに注意を払います！