1

私は、共同SQLServerデータベースで数千の小規模な顧客をホストするaspxアプリケーションを作成しています。すべてのエンティティは、Linq-To-Sqlを介して作成およびロードされます。

代理キー（ID列）はすべてのテーブル関係のスキーマ全体で使用されるため、ルートカスタマーオブジェクトから始めて、通常のLinqクエリ（SQL結合）を使用して特定のカスタマーの排他的なデータセットに移動できるはずです。

ただし、セキュリティの観点から、上記は少し壊れやすいので、セキュリティのバックストップとしてテナンシーチェックのレイヤーを追加したいと思います。私のエンティティモデルのすべてのエンティティには、インデックス付けされていないintTenantIdフィールドがあります。

パフォーマンスの観点から、このソリューションに関する批判的なコメントを探しています。

public partial class MyLinqEntity

  partial void OnLoaded() // linq-to-sql extensibility function
  {
    if ( this.TennantId != HttpContext.Current.Session["tenantId"] )
      throw new ApplicationException("Logic error, LINQ query crossed tenantId data                      boundary");
  }

  partial void OnCreated() // linq-to-sql extensibility function
  {
    this.TennantId = HttpContext.Current.Session["tenantId"] );
  }
4

1 に答える 1

0

申し訳ありませんが、これはほとんどランダムな考えです…。

HttpContext に依存するすべてのオブジェクトが好きというわけではありません。

また、各オブジェクトのセッションを調べるのが十分に速いかどうかもわかりません。データベースのルックアップは通常、処理中の処理よりもはるかに遅くなるため、速度については問題ないと思います。

依存性注入フレームワークを使用して、チェックを行うためのセッション スコープを持つオブジェクトを自動作成する傾向があります。ただし、他の場所で依存性注入フレームワークが必要ない場合、これはやり過ぎです。

すべてのデータベース行に tenantId 列があるため、チェックを linq-to-sql の「行読み取りコールバック」に移動して、各オブジェクトに配置する必要がなくなることを願っています。「linq-to-sql」についてはわかりませんが、クエリ作成フレームワークにフックして、すべてのデータベース クエリに「where tenanted = xx」を追加できると思います。

すべての採石場で「where tenanted = xx」を設定すると、顧客の必要に応じてデータベースを分割できるため、「テーブル スキャン」などの費用が安くなります。

于 2009-09-03T11:25:51.887 に答える