我应该使用扩展方法来帮助从 DataRow/Table 创建模型对象吗？

Question

我目前使用一些重复的代码 - 更具体地说，处理从 DataRow 和 DataTable 创建模型对象的代码。我认为创建扩展方法来减少重复代码并添加一些语法糖是安全的。

我之前有什么（简化）：

public List<MyObject> GetThings(){
    DataSet dataSet = SomeDatabaseCall();

    var objects = new List<MyObject>();
    foreach(DataRow row in dataSet.Tables[0].Rows){
        //Process Row, create object, add to objects
    }
    return objects;
}
public MyObject GetThing(int id){
    DataSet dataSet = SomeDatabaseCall(id);
    DataRow row = dataSet.Tables[0].Rows[0];
    //Process Row, create object, return it
}

之后我想要什么：

public List<MyObject> GetThings(){
    DataSet dataSet = SomeDatabaseCall();
    return dataSet.ToMyObjects(); //Internally calls the ToMyObject for each row
}
public MyObject GetThing(int id){
    DataSet dataSet = SomeDatabaseCall(id);
    DataRow row = dataSet.Tables[0].Rows[0];
    return row.ToMyObject();
}

问题：

有人向我指出，以这种方式使用扩展方法很危险，我应该使用采用 DataRow 的简单静态函数来处理数据（本质上是不带 this 参数的扩展方法）。

问题：

扩展方法在这种情况下有意义吗？为什么这种做事方式会被认为是危险的？

Answer 1

扩展方法并不比创建静态方法更危险，因为扩展方法编译为静态方法。它们只是为程序员带来好处的语法糖。您可以自己比较IL，但这里有一篇文章和一个示例，可以帮助您说服您的同事扩展方法并不危险：扩展方法如何工作？

Answer 2

我不认为这样做有什么危险；只要您能够控制所有代码，并且数据集的布局就不会在您的控制下发生改变。这似乎正是扩展方法的设计目的。

我很想知道这是“危险”用途这一说法背后的原因。

Answer 3

如果您将扩展方法放入特定于您的项目的库中，那么您就不会冒用您的特定扩展玷污其他项目的风险。我也不明白这有什么危险。

更新：好的，我明白你的观点了，@Pwninstein：你调用扩展的DataRow很可能是任何东西。 但是，拥有一个采用 DataRow 作为参数来创建对象的方法不再危险。