ASPを使用する多くのWebサイトはコンポーネントをまったく使用していませんが、この記事では、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セッションまたはアプリケーション変数にオブジェクトを保存するという悪い習慣を身に付けることができます。