最近では、ASPを使用する多くのWebサイトはコンポーネントをまったく使用していません。本日、Fooxin Technology Channelの編集者は、ASPとコンポーネントの間の分割サービスについて簡単に説明しています。この知識を学ぶことが役立つことを願っています。
ASPおよびコンポーネント部門サービス
ASPは、サーバー上のクライアントが使用するためのHTMLまたはXMLファイルを作成するために最も一般的に使用されるため、主にこの使用シナリオについて説明します。これにより、一般的な質問が表示されます。ASPページがサーバー上にある場合、それらはビジネスレイヤーの一部に属しますか？コンポーネントの世界では、答えは通常ノーです。 ASPはサーバーで実行され、アプリケーションサーバーと同じスペースにある場合がありますが、これはビジネスロジックの一部になりません。
ユーザーインターフェイスツールが成長しているか、より多くのビジネスからビジネスへのソリューションが有効になっているため、この明確な区別を持つことで大きな報酬が返済されます。
そうは言っても、最も重要なビジネスレイヤーおよびプレゼンテーションレイヤー分割基準のいくつかを見てみましょう。
UIコードをビジネスロジックから分離します。これには、ASP内部コンポーネントを使用してビジネスロジックコードから分離するMTSオブジェクトを使用するなど、UIに組み合わせたコードの作成が含まれます。
ASPページから個別のトランザクション。トランザクションASPは場合によっては非常に優れていますが、コンポーネントとマルチ層アプリケーションはこれを変更します。コンポーネントは、クライアントレイヤーに依存して、トランザクションとビジネスロジックセマンティクスを管理する必要があります。
Webサーバーと同じマシンおよび/またはプロセスに、表現コンポーネント（リクエストと応答を使用するコンポーネント）を配置します。 ASP内部コンポーネントオブジェクトを使用するオブジェクトがリモートマシンに配置されている場合、内部コンポーネントへのすべての呼び出しがコールバックフォームで発生します。 IISクライアントを呼び出すcom+サーバーはcom+サーバーであり、パフォーマンスを大幅に削減し、セキュリティ構成を複雑にします。これらの微調整オブジェクトは、「ライブラリアクティベーション」とマークされたcom+アプリケーションに配置できます。
ASPはサーバーに存在するため、ASPページはリソース共有ルールに準拠し、スケーラビリティに留意する必要があります。以下の詳細をご覧ください。
「セッション」では、経営陣はユーザー固有のステータスを回避しないようにする必要があります。
ASPをステートレスに保ち、可能な限りリソースプールを許可します。
操作方法
コードセグメントがビジネスロジックまたはプレゼンテーションレイヤーに属するかどうかを評価する場合、「ASPページをボタンタイプの電話アプリケーションに置き換える必要がある場合は、そのコードはまだ便利ですか？」答えが「はい」の場合は、ビジネスロジックコードまたはユーザーインターフェイスヘルパーコードに分割することを試みることができます。
クライアントを変更した後にコードを使用できない場合、またはユーザーインターフェイスを構築するためのヘルパーである場合、コードは表現サービスレイヤーに属します。 ASPページ、またはASP内部コンポーネントを使用するコンポーネントにあります。ビジネスオブジェクトコンポーネントに属していません。
デスクトップクライアントとASPクライアントの違いを理解します
ASPは、デスクトップ上の従来のシングルスレッドWin32アプリケーションとは異なり、コンポーネントの特別なクライアントです。主な違いは次のように要約されています。
スレッド管理：ASPはマルチスレッドクライアントです。これは、多くの同時アクティビティが一緒に実行され、おそらく同時に異なるASPページを処理することができることを意味します。これは、オブジェクトがシステムを独占的に占有する唯一のユーザーであると誤って主張することができないことを意味します。これを行うと、たとえば、ASPセッションまたはアプリケーション変数にオブジェクトを保存するという悪い習慣を身に付けることができます。
セキュリティ環境：ASPは、Webサイトのインターネット情報サービス5.0によって実行され、3つの分離レベルの低、中、高。これらのWebサイトでさえ、さまざまなセキュリティ設定を行うことができ、匿名アクセスを許可または拒否し、顧客を認証するなどです。これらのすべての設定は、異なるユーザーアカウントがオブジェクトを使用することになる多数のスキームを作成します。
簡単に成長する：これは技術的な問題ではなく、Webアプリケーションが提供する施設の副作用です。
従来、ユーザーベースをデスクトップアプリケーションに追加するには、既知の数のクライアントへの転送を慎重に計画する必要があります。 ASPはプロセスを変更しました。稼働後、すべての従業員、すべてのビジネスパートナー、およびすべての顧客がローカルまたは世界中で使用するために、ASPビジュアルの基本アプリケーションを簡単に開くことができます。
この方法で説明できます。ハイパーリンクを使用した単一の電子メールは、ユーザーベースを10倍に増やすことができます。あなたのアプリケーションはこれに向けて準備ができていますか？知る唯一の方法は、実際のパフォーマンスの期待値を得るために、Webサイトで強度テストを行うことです。
ASP内の視覚的な基本オブジェクトをどのように使用する必要がありますか？ページスコープ内でオブジェクトを作成してキャンセルします。
つまり、ASPページを可能な限りステートレスにし、一時的な状態のセッションまたはアプリケーション変数のみに依存します。セッションまたはアプリケーション変数にオブジェクトを保存しないでください。これにより、ASPスレッドがセッションにロックされ、スケーラビリティのためにすべての期待値がキャンセルされます。つまり、Webサーバーによって処理されたユーザーの数は、数十人のユーザーを超えません。セッションまたはアプリケーションにコンテンツを保存する必要がある場合は、オブジェクトではなくデータにしてください。
他にも多くのガイドラインがあります。 JD MeierがMSDN Voicesで書いた「Servin ’It Up」というコラムを読むことをお勧めします。このコラムには、スケーラブルで信頼性の高いASPおよびコンポーネントアプリケーションの開発に役立つ幅広い技術、プラクティス、ヒントが含まれています。
セッションまたはアプリケーションでVBオブジェクトに参照を保存しないでください
すべてのVisual Basic 6.0コンポーネントは「ユニットスレッド」です。つまり、すべてSTAユニットで実行されます。これは、オブジェクトがスレッドで作成されている場合、そのオブジェクトへのすべての呼び出しが同じスレッドで提供される必要があることを意味します。多くのスレッド（同時のWebサイトユーザーから）は、STAオブジェクトの同じインスタンスを使用して、アプリケーションでボトルネックになる可能性のある一連のアクティビティを引き起こします。
さらに、Server.CreateObject内で作成されたSTAオブジェクトを保存すると、実行スレッドを現在のユーザーに効果的に連絡することができ、アプリケーションの同時ユーザーの最大数をデフォルトの20XN（n =プロセッサ数）に制限します。
操作方法
オブジェクトをステートレスにするための推奨事項に従って、クライアントの再利用のための参照を保存して、アプリケーションスコープ内に保存する必要はありません。クライアントは、独自のオブジェクトを独立して作成、使用、キャンセルできます。これにより、セッション固有の状態を保持しないため、セッション固有のオブジェクトを維持する必要性が軽減されます。
推奨される方法は、必要に応じてデータベースまたはその他のストレージエリア（CookieやLDAPなど）にアクセスするオブジェクトをステートレスにすることです。
セッションまたはアプリケーション全体のデータを使用する必要がある場合は、ここでデータを処理するオブジェクトではなく、データを保存します。目的の値の処理をカプセル化するクラスを作成できます。
IIS 5.0で新しいコンテンツを学びます
インターネット情報サーバー5.0は、多くの新機能を追加します。これらの改善は、JD MeierのMSDN記事：IIS 5.0（英語）でASPを使用して書かれています。
上記は、ASPとFalse New Technologyチャネルの編集者が共有するコンポーネントとの間の部門サービスの簡単な説明です。この側面についてもっと知識があることを願っています。これはASPの開発に役立ちます。