实用程序类与子类.net控件

I want to reuse some code I wrote to add some functionality to a datagridview. I want the default datagridview properties and events to be exposed, so I didn't want to create a new custom component. so I tried writing a subclass, which works fine. but it also occurred to me that I could write a standalone utility class that takes a datagridview in the constructor and sets it up the same way. e.g.

我想重用我编写的一些代码来为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
    }
}

so somewhere in my app's startup I would call

所以在我的应用程序启动的某个地方,我会打电话

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

and so forth. any disadvantages to this approach? it seems like much of the code is going to be the same, the difference is between how you instantiate the extended grid (drag and drop a subclassed control to the form vs drag a plain datagridview and call the above code)

等等。这种方法的任何缺点?看起来大部分代码都是一样的,不同之处在于如何实例化扩展网格(将子类控件拖放到表单中,拖动普通数据网格并调用上面的代码)

3 个解决方案

#1

The only disadvantage of a utility class, is that you lose the designer support. Meaning, if you subclass the control, when you add it to the designer, any changes you make in the constructor of your inherited control will show up in the designer. Furthermore, if you want to add some properties to it, they will show up in the properties window, giving it even more flexibility. If designer support doesn't matter to you though, then I don't see any other drawbacks to a utility class.

实用程序类的唯一缺点是您失去了设计器支持。这意味着,如果您将控件子类化,则在将其添加到设计器时,您在继承控件的构造函数中所做的任何更改都将显示在设计器中。此外,如果要向其添加一些属性,它们将显示在属性窗口中,从而为其提供更大的灵活性。如果设计师支持对你来说无关紧要,那么我没有看到实用程序类的任何其他缺点。

#2

In the long run, a utility class will be more maintainable than a subclassed control unless you are doing something more substantial to extend DataGridView than modifying sorting.

从长远来看,实用程序类将比子类控件更易于维护,除非您正在做一些更大的扩展DataGridView而不是修改排序。

Your approach for the utility class (taking a DataGridView in the constructor) is a solid approach.

您对实用程序类的方法(在构造函数中使用DataGridView)是一种可靠的方法。

#3

If you're using C# 3, extension methods might be worth a look. Looks like you're adding behavior to a type, that you wished existed out of the box.

如果您使用的是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
}

#1

#2