0

アプリケーション アーキテクチャに関するアドバイスの大部分は、(疎結合を促進し、依存関係を減らし、テスト容易性を高めるために) HTTPContext にアクセスできるのはプレゼンテーション レイヤーだけであるべきだと強くアドバイスしているようです。

では、人々はキャッシングとセッションをどのように扱うのでしょうか? アプリケーションのパフォーマンスを最大化するためにキャッシュが必要な項目を判断するには、非常に具体的な DataAccess とビジネス ロジックの知識が必要です。ただし、ASP.Net Web アプリケーションでは、これらへのアクセスは HTTPContext を介して提供されます。

1 つのオプションは、CacheFactory と SessionFactory、および ICache と ISession インターフェイスを作成することです。その後、何らかの方法で DI 原則を使用して、ISession と ICache を BLL の各メソッドに渡し、続いてそれを必要とする DA レイヤーに渡します。

これは本当に開発者が最終的に行うことですか? これに対処する別の簡単な方法はありますか？

アドバイスをありがとう。

4

2 に答える 2

1

個人的には、ASP.NET (Web) のみを対象として開発していて、クラス ライブラリが Web のみをターゲットにすることがわかっている場合、必要に応じて System.Web やその他のアセンブリを参照しても問題はありません。時には実用性を第一に考えるべきです。

一方、BLL、DAL、またはその他のレイヤーがクライアント サーバーまたはその他の環境で再利用される可能性があるかどうかがわかっている場合、または不明な場合は、セッション ハンドラー インターフェイスなどのより柔軟なアプローチの使用を検討する必要がある場合があります。 .

重要なことは、ベスト プラクティスで推奨されていることを明確に理解することです。その時点で、各プロジェクトまたは状況に適用すべきものについて合理的な決定を下すことができます。常に手袋のようにフィットするとは限りません。

于 2010-09-02T17:27:29.527 に答える
0

私の経験では、キャッシュは特定のレイヤーで行われ、キャッシュしているものはそのレイヤーの範囲内で適用されるため、次のようになります。

  • DAL にデータをキャッシュして、DAL が DB に再度アクセスするのではなく、メモリからデータを返すようにすることができます。ここでは、データ レベルで「生」データをキャッシュしています。
  • BL は同様のデータ (POCO など) をキャッシュする場合があります。つまり、BL が適用された「論理」データです。ここでは、BL データを BL レベルでキャッシュしています。
  • UI は、UI レイヤーで構築された情報をキャッシュする可能性があります (ご想像のとおり)。Web ページ、XML などとしてのデータのプレゼンテーションのようなものです。

キャッシングを見ると、システムのアーキテクト/デザイナーとして、キャッシングする価値のあるものについて決定を下すことになります。一般的に、これはバランスをとる必要性によって推進されます。

  • パフォーマンスは特定の目標を達成する必要があります。
  • 利用可能な時間 (および費用) オプション。

パフォーマンスを向上させるためにキャッシングを行っていると仮定すると、システムを分析して、除去または回避する必要があるボトルネックを特定する必要があります。この分析の最初のパスでは、少なくとも最初に注目すべきレイヤーを特定する必要があります。

考慮すべきもう 1 つの点は、消費者の近くにキャッシュできるほど、実行する必要がある全体的な処理が少なくなるということです。言い換えれば、UI レイヤーでキャッシュできる場合、BL レイヤーと DAL レイヤーはルックインさえ取得しません (そこにキャッシュを追加する必要はありません)。

この時点で、あなたが達成しようとしていることは正確には何なのかをお聞きしたいと思います。

私が言ったことはすべて真実ですが (私の知る限り)、それはすべて、システム機能の「垂直」スライス (「請求書の作成」、「製品の追加」など) を提供しているという前提に基づいています。 ; 適用できるモデルがもう 1 つあります。分野横断的関心モデルです。

ロギングのようなものを考えてみてください。システムのすべての部分 (UI / BL / DAL) でシステム イベントをログに記録できる必要があります。このための私のお気に入りのツールは、MS Enterprise Libraries (MSEntLibs) です。彼らと一緒に仕事をするとき、私は彼らを「ブラックボックス」、つまり自己完結型のユニットだと考えています。私は（選択により）それらがどのように設計されているかわかりません-重要なことは、それらが分離されており、比較的管理が容易な依存関係があることです。

MSEntLibs はデータベースにログを記録できますが、(DB にログを記録するために) MSEntLibs ログ記録メソッドを UI から直接呼び出しても (そして BL をスキップしても)、気にしません。

したがって、何をしようとしているかに応じて、正しい回答は次のいずれかになります。

  • 適切なレイヤーに処理させる際に、キャッシュする必要があるものを特定するだけです。
  • BL に何かを渡すために DI を使用する必要はまったくありません。横断的なブラック ボックス コンポーネントが適切でしょうか?
于 2010-09-02T22:18:33.910 に答える