2

基礎となるデータセットの繰り返しの変更に対して最適化された、.NET 用のデータ対応グリッドを探しています。ほとんどすべてのグリッドでデータソースを変更できるため、そのコンテキストでの最適化の意味を示す例を示します。しかし、OCX の時代にさかのぼると、データソースを変更すると、データ対応グリッドに問題が発生しました。

このデータベース対応のデータ駆動型グリッドは、整数の行ハンドルを使用してはなりません。GUID 行ハンドルを使用する必要があります。これが、このグリッドの最も重要な要件です。

基になるデータセットの各行には、整数ではなく GUID の rowHandle が割り当てられます。データ行がどのように並べ替えられたりグループ化されたりしても、データ行の GUID の rowHandle は保持され、データ行はその rowHandle によって即座に取得できます。

グリッドのFocusedRowChangedイベントは、現在フォーカスされている行の GUID が、最後にフォーカスされた行の GUID と異なる場合に発生します。 [編集: 整数行ハンドルを使用するグリッドでは、データソースが変更されたときに FocusedRowChanged イベントが発生しないことがよくあります。これは、focused-row-position が変更されていないためです。たとえば、データソースの変更前は最初の行にフォーカスがあり、データソースの変更後は最初の行にフォーカスがあります。基礎となる行データが完全に異なっていても、整数行ハンドルは同じです。]

私は、グリッドがその動作において真にデータを認識し、データ駆動型であることを望んでいます。例えば

Grid.GroupByColumnNames = {"customername","city"};
Grid.Groups["customername"].ExpandedValues = {"Acme Widgets", "Foo Industrial"};
Grid.Groups["city"].ExpandedValues = {"New York","Miami"};

ここで、上のグリッドの下にあるデータセットをクリアし、そのデータソースを別のデータセットに置き換えた場合、そのデータソースには顧客名と都市の列があり、その列に Acme Widgets と Foo Industrial の値が含まれていました。グリッドは新しいデータセットを顧客名でグループ化します。および市の列を展開し、それらの会社を展開します (PreserveGroupingsWhenDataSetChanges フラグが True に設定されている場合)。

4

1 に答える 1

0

この質問には根本的に間違った点があり、数か月経っても誰も良い答えを出していないのです。データの主キーが GUID であっても、コントロールの行ハンドルを GUID にすることは正当化されません。実際、これはかなり悪い考えです。GUID は 128 ビット (16 バイト) ですが、int は通常 32 ビットですが、ビット数 (特定の環境では 64 だったとします) よりも重要なのは、int 操作がアトミックであることです。スレッド化され、より高性能です。そのため、GUID はメモリ フットプリントが高く、処理コストが高くなります (読み取り/書き込みはそれぞれ複数の操作になります)。

したがって、実際には、コントロールは高速でリーンなコードを視覚的に使用し、必要に応じてデータソースを参照して主キーまたはその他のデータを取得する必要があります。

グリッドに関する私の経験と考え

私はたまたま winform 用の DevExpress コントロールが好きで、データ層コンポーネント XPO も使用しています。ただし、同様のコントロールとデータ レイヤーを備えた複数のコンポーネント ベンダーが存在します (一般に、行ハンドルをデータ主キーから分離する機能を共有しています)。

DevExpress には、データに対応した優れたグリッドがあり、あらゆる種類の可能な変更に結び付けるための多数のイベントを提供します。

そこでは、XPO データレイヤーは、int または Guid を含む主キーに何でも使用できます。リモート マシンまたはオフライン データから主キーを挿入できるため、他の多くの開発者と一緒に Guid を使用しています (1 つのテーブルに 20 億件を超えるレコードがあるデータベースを担当したことがあるとは言えませんが、多分あなたは)。

私のデータの主キーは GUID かもしれませんが、行ハンドルはまだ int です。これは、Guid よりも舞台裏で大幅に高速になります。ただし、ビジュアル インデックス、行ハンドル、およびデータ ソース インデックスの間を行き来するための一連のメソッドと、行ハンドルによって基になるデータ ソース行をフェッチするためのいくつかのメソッドが提供されます。これは、行ハンドル (データ主キーではない) を提供する多くのコントロール イベント内で役立ちます。この場合、1 行のコードで行ハンドルによってデータ ソース レコードを簡単に取得できます。

また、一般的に言えば、上記の疑似コードのように文字列ベースのインデクサーを使用してコレクションにアクセスする場合、コンポーネントList.IndexOf()はバックグラウンドで一種の呼び出しを行い、それが int インデックスとしてインデクサーに渡されます。したがって、実際にはまだ舞台裏で int ベースのインデックスを使用しています。一部のコンポーネント会社が行ハンドルに GUID を使用していたとしても、それらの GUID を舞台裏でハッシュセットまたは辞書に入れ、実際に使用する int インデックスを検索していたでしょう。いずれにせよ、それはすべて int の上にあるレイヤーにすぎないので、抽象化したままにして、必要に応じてコードにこの種のものを実装できるようにします (コンポーネント ライブラリにビルドするのではなく)。

おすすめ

要するに、DevExpress グリッドを使用して上記のすべてを達成できると思いますが、GUID の行ハンドルを手放し、戦略を少し変更する必要があります。アプリケーションでこの種の逆引き参照が必要な場合は、独自の GUID を行ハンドル インデックスにハッシュセットまたはディクショナリとして作成する必要がある場合があります。これにより、すべての行ハンドルが常に GUID である場合にパフォーマンスの問題を回避できますが、GUID と行ハンドルの間で順方向と逆方向の両方の変換が可能になります。

于 2011-11-17T23:34:11.740 に答える