3

WebControlを拡張するカスタムコントロールを作成しています。このWebコントロールを使用すると、コンシューマーは次のようにマークアップで列のコレクションを定義できます。

<Custom:CustomGrid>
<Columns>
    <Custom:DataColumn HeaderText="FirstName" />
    <Custom:DataColumn HeaderText="LastName" />
</Columns>

IEnumerableをDataSourceプロパティに配置すると、これがテーブルにレンダリングされます。このコントロールでは、ページングも可能です。DataSourceのIEnumerableは完全なリストであり、一度にリストのページを表示します。現在のページ、ページあたりの行数などをviewstateに保存しています。また、完全なリストをビューステートに入れる必要がありますか？多分セッション？このリストは少し重くなる可能性があります。たぶん、ビューステートに保存されているランダムキーを使用してセッションで保存しますか？ここでのベストプラクティスは何ですか？

編集： IEnumerableのすべての型をシリアライズ可能にすることを強制するのは正しいとは思いません。それは公平ですか？では、シリアル化のためにデータソースを他のデータ構造にコピーする必要がありますか？

編集2： RenderChildControlsを実装する代わりに基本コントロールを使用する場合でも、CreateChildControlsを実装する必要がありますが、データをどこかに永続化する必要がありますか、それとも基本クラスのポイントを逃しましたか？

4

2 に答える 2

2

実際、すべてのIEnumerableインスタンスがシリアル化できるわけではありません。

クエリの実行が安価な場合は、データセット全体を永続化するのではなく、別のページまたは並べ替え順序の変更に対してクエリを再実行するだけです。

データをビューステートにすると、巨大なページになってしまいます。ユーザー数が少ない場合はセッション状態は許容できるかもしれませんが、ユーザー数が多い大規模なデータセットは適切にスケーリングされません。100万行をコントロールにバインドするとどうなりますか？または、コントロールがリピーターで使用され、ページに100回表示された場合はどうなりますか？

データを永続化する必要がありますか？これは時期尚早の最適化ではありませんか？

コントロールはUIコンポーネントであることを忘れないでください。ビューステートは、UI状態をそのまま維持するのに十分な情報を保持する必要があります。状態の変化（例：結果の別のページへの切り替え）は、コントロールがデータソースに責任を渡す必要があるものです。

古き良きを見てくださいGridView。それはあなたがそれを与えたものを表示し、それを覚えています。ページングを使用している場合は、「ユーザーがページを変更しました。データのページxを教えてください」というイベントが発生します。私にとって、これはUIコントロールのベストプラクティスです。

于 2012-12-03T10:07:54.697 に答える
0

データバインド制御を実装するには、そのようなタスクを実行するように設計された基本クラスを使用することをお勧めします。たとえば、ASP.NETには、カスタムデータバインドコントロールを実装するための基本クラスとして使用できるCompositeDataboundControlが存在します。次のDinoEspositoの記事を確認することをお勧めします：http： //msdn.microsoft.com/en-us/library/aa479016.aspx。

基本的に、ASP.NETグリッドビューのようなコントロールを作成する場合、それはビューステートに値を格納します。より明確にするために、ビューステートに割り当てられた値を保存したDataRowコントロールの数を作成します。ポストバック中に、同じ数の行が再作成され、値がビューステートから復元されます。たとえば、ビューステートを使用せずにセッションでデータソースのみを保存する場合は、ポストバックのたびにデータをグリッドに再データバインドする必要があります。したがって、gridviewと同様のサーバーコントロールを作成する場合は、Dino Espositoの投稿で説明されているアプローチが、ASP.NETServerGridViewコントロールと同様のコントロールを作成する方法を示しているため非常に役立ちます。

于 2012-11-23T18:43:46.500 に答える