2

維持している ASP クラシック サイトがあり、オブジェクトとプロパティへのアクセスを統合したいと考えています。特定のオブジェクトのデータを取得し、データを挿入し、データを更新するためのプロパティを持ついくつかの単純なクラスを作成しました。これらのクラスのほとんどは、1 つのテーブルに対応しています。

画面の HTML 出力の作成などをどこで行うべきか、または複数のクラスを使用するメソッドをどこに置くべきかを考えています。たとえば、課題と生徒の情報を使用して出力を生成する生徒の学年クラスがあるとします。

オブジェクトからレコードセット (または配列?) を取得して出力をレンダリングする「プレゼンテーション」クラスを作成する必要がありますか?

ありがとう！！

4

2 に答える 2

1

まず、そのために WSC を使用することをお勧めします。クラスとは異なり、WSC は条件付きでロード/実装できます。私が働いている会社では、WSC を使用して非常に安定した高速な多層 ORM を構築しました。WSC はスクリプト コードで記述されたオブジェクトであり、プロパティとメソッドがあります。

WSCの説明
WSCの例

あなたと同じように、テーブルごとに WSC があり、列のプロパティがあります。さらに、各 WSC には、ID を受け入れる initialise() メソッドがあり、その ID のデータベースからの値を使用してすべてのオブジェクト プロパティをロードします。save() メソッドもあります。これは、id が存在するかどうかをチェックします。そうでない場合は、INSERT を実行します。ID がある場合、これは既存のレコードであり、UPDATE を実行します。また、delete 関数 () もあります。特定のテーブルに対してこれらの WSC をオンザフライで生成できる小さな ASP Web ページがあります。

WSC 内には、WSC 内のすべてのクエリを実行するデータ アクセス レイヤー オブジェクトがあります。すべての WSC は SQL 文字列を作成して DAL に送信するだけで、DAL はレコードセットを返します (または結果なしで実行します)。この DAL は、データベースへの接続文字列を知る必要がある唯一のコンポーネントです。必要に応じて、すべてのクエリをログに記録するためにも使用できます。

また、ロギング/デバッグ用、変換用の WSC と、SQL インジェクションを防ぐためにすべての SQL をエスケープする非常に重要な WSC もあります。

質問に戻ります。

通常、ロジックとプレゼンテーションをできるだけ分離しようとします。asp.net mvc や django などの最新のフレームワークでは、ページに情報を渡すことができるのは、追加できる汎用ディクショナリ内か、ページに渡すモデル内だけです。(クラス マップ テーブルの 1 つであるモデル)。この動作を模倣できれば、ロジックとコードを適切に分離できます。

あなたが説明した問題を解決するために私たちが何をしたかをお話ししますが、私たちの解決策は理想的ではなく、ゼロから始めるとしたらどうするかについてもお伝えします。

現在のアプリケーションで行っていることは、WSC にメソッドを追加することです。したがって、user() wsc がユーザー テーブルにマップされていると仮定すると、既に次のようなことができます。

user.firstname = "erik"
user.lastname = "test"
user.save()

この WSC に「user-stuff」を追加します。おそらく login() 関数のように、ユーザー名とパスワードを受け取り、ユーザー ID を返します (ログインが失敗した場合は何も返しません)。

dim userid
    userid = user.login("test", "test")

このように、特定のエンティティに属するロジックを、それが属する WSC に配置することで分離します。

したがって、実際に行うことは、オブジェクト自体にロジックを追加することです。これは、真の OO スタイルで行われる方法ではありません。真のオブジェクト指向プログラミングでは、オブジェクト (ユーザー オブジェクトなど) をパラメーターまたは関数の結果として渡し、(処理) ロジックを分離したままにします。クラシック ASP は真のオブジェクト指向ではないため、ロジックをオブジェクト自体に追加することにしましたが、後から考えると、必要に応じてクラシック ASP でこれらの方針に沿った何かを実現できる可能性があります。

また、それらがどこに属しているかという問題を提起するいくつかの手順があります。書式設定された PDF レターをユーザーに送信する場合、ロジックはユーザー オブジェクトまたはレター オブジェクトのどちらに入りますか? 私たちがこれに答える方法は、コードを見るだけです。ユーザー WSC は既に使用可能で初期化されていますか? 次に、ユーザーにメソッドを簡単に追加できます。レターを一括送信する必要があり、開いている letter.wsc から開始する場合は、レター wsc に機能を追加します。正直なところ、それはほとんど自分自身を手配します。

ビジネス ロジックと ORM (テーブルをクラスまたは WSC にマッピングする) を完全に分離する場合、この問題は発生しません。そのため、最新の OO 言語はこの問題に対する優れたソリューションです。従来の ASP では、処理ロジックを ASP ページに配置することでこれを行うことができました。オブジェクトは処理ロジックによって使用されるだけです。

現在、データベースに情報を格納できる専用の WSC を用意しています。1 つの ASP ページで処理しますが、表示しません。代わりに、この WSC に結果を入れます (大きなキー値テーブルに格納されます)。次に、同じ WSC/テーブルのデータを表示する別の ASP ページにリダイレクトし、コード フォーム ロジックを分離します。

クラシック ASP の memcached

少し前から、従来の ASP から memcached を使用できるようになりました。memcached は完全にメモリ内のキー値ストレージであり、facebook でも使用されています。ストレージ用のデータベースよりもはるかに高速です。最初からやり直す場合は、次のように実装します。

  1. WSC を使用して、現在のような ORM を作成します
  2. ビジネス ロジックを WCS に入れずに、既定で ASP ページに入れます。
  3. aspページに結果をmemcachedに保存させます（これは単純な変数にすることができますが、vbscriptの代わりにjscriptで作業している場合は、シリアル化されたレコードセットまたはjsonオブジェクトでさえも可能です）
  4. memcached に保存されている情報を表示できるプレゼンテーション ページにリダイレクトします。

くそったれ、Caveatrob、ご覧のとおり、私はこのことにかなり情熱を注いでいます。これを実装するための小さな本を書いたようです。これを最初からやり直すのは大変な作業であり、あなたが求めた以上のことを言ったことに気づきましたが、書いた後にこれを削除したくありませんでした.
おそらくこのフレームワーク全体を実装することはないでしょうが、いくつかの情報があなたにとって有利に働くことを願っています。（もしそうなら、私に知らせてください:)）

エリック

于 2012-08-23T08:39:23.583 に答える
0

私が働いているところでは、「ページ」を次のように書きます。

コントローラの開始

ページ コントローラー コード (SQL クエリ、パラメーター、セッションなど)

ここでは、プレゼンテーションの全体を計算し、ユーザー アクションに対応します。

終わり

プレゼンテーションを開始

共通のhtmlフラグメント（ページネーション、共通スクリプトなど）とコントローラー側で用意したデータをサーバーサイドインクルードしてhtmlページを表示します。

プレゼンテーションを終了

プレゼンテーション側では (どこでどのように行っても)、オブジェクト メソッドを呼び出して、必要に応じてデータを表示/取得します。

本当に一般的でない限り、ビジネスオブジェクトのプレゼンテーションはクラスにカプセル化するのではなく、他の場所に置くべきだと思います。

オブジェクトに異なるレンダラーを実装するいくつかのクラスを構築できるかもしれません。しかし、ほとんどの場合、プレゼンテーション全体をオブジェクトにカプセル化するのは難しいと思います:(

お役に立てれば！乾杯！

于 2012-08-23T12:34:34.050 に答える