5

作成したコードを再利用して、datagridviewに機能を追加したいと思います。デフォルトのdatagridviewプロパティとイベントを公開したいので、新しいカスタムコンポーネントを作成したくありませんでした。だから私はサブクラスを書いてみましたが、それはうまくいきます。しかし、コンストラクターでdatagridviewを取得し、同じ方法でセットアップするスタンドアロンのユーティリティクラスを作成できることにも気づきました。例えば

public class
MyGrid
{
    private DataGridView m_dg;

    public MyGrid(DataGridView dg)
    {
        m_dg = dg;
        m_dg.RowHeadersVisible = false;
        m_dg.SortCompare += new DataGridViewSortCompareEventHandler(m_dg_SortCompare);
    }

    void m_dg_SortCompare(object sender, DataGridViewSortCompareEventArgs e)
    {
        // do custom sorting here
    }
}

だから私のアプリのスタートアップのどこかで私は電話します

MyGrid g1 = new MyGrid(dataGridView1);
MyGrid g2 = new MyGrid(dataGridView2);

などなど。このアプローチの不利な点はありますか？コードの多くは同じになるようですが、違いは、拡張グリッドをインスタンス化する方法（サブクラス化されたコントロールをフォームにドラッグアンドドロップする方法と、プレーンなデータグリッドビューをドラッグアンドドロップして上記のコードを呼び出す方法）の違いです。

4

3 に答える 3

3

長期的には、ソートを変更するよりもDataGridViewを拡張するためにもっと実質的なことをしているのでない限り、ユーティリティクラスはサブクラス化されたコントロールよりも保守しやすくなります。

ユーティリティクラスに対するアプローチ（コンストラクターでDataGridViewを使用する）は、堅実なアプローチです。

于 2009-06-24T14:03:26.667 に答える
1

ユーティリティクラスの唯一の欠点は、デザイナーのサポートが失われることです。つまり、コントロールをサブクラス化する場合、それをデザイナーに追加すると、継承されたコントロールのコンストラクターで行った変更はすべてデザイナーに表示されます。さらに、いくつかのプロパティを追加する場合は、プロパティウィンドウに表示されるため、柔軟性がさらに高まります。ただし、デザイナーのサポートが重要でない場合は、ユーティリティクラスに他の欠点はありません。

于 2009-06-24T14:15:23.773 に答える
1

C＃3を使用している場合は、拡張メソッドを一見の価値があります。箱から出して存在したいと思っていた動作をタイプに追加しているようです。

static class GridExtMethods
    {
        public static void SortAsICommand(this MyGrid grid)
        {
            //grid.Prop = value; possible
            grid.Sort += MyCustomSort;
        }
        static void MyCustomSort(object sender, SortEventArgs evtArgs)
        {
            Console.WriteLine("Sort {0} and {1}", evtArgs.First, evtArgs.Second);
        }
    }

...。

static void Main()
{
   var grid = new MyGrid(10,20);
   grid.SortAsICommand();

   //grid.RaiseEvent(); do something that raises the event
}
于 2009-06-24T15:53:08.203 に答える