Je travaille actuellement avec du code qui est répété - plus spécifiquement, du code qui traite de la création d'objets modèles de DataRow
s et DataTable
s. Je pensais qu'il serait prudent de créer des méthodes d'extension pour réduire ce code répété, et ajouter du sucre syntaxique.Dois-je utiliser des méthodes d'extension pour faciliter la création d'objets de modèle à partir d'un DataRow/Table?
Ce que j'avais avant (simplifié):
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
}
Ce que je veux Après:
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();
}
Le problème:
Il a été signalé à moi que l'utilisation de méthodes d'extension de cette manière est dangereuse, et que je devrais utiliser des fonctions statiques simples qui prennent un DataRow
à la place pour traiter les données (essentiellement une méthode d'extension sans le paramètre this
).
La question:
Would Méthodes d'extension de sens dans ce scénario? Et pourquoi cette façon de faire serait-elle considérée comme dangereuse?
Qu'est-ce que la personne qui a dit être dangereuse a dit qu'elle était dangereuse pour elle? – Sorax
Essentiellement, s'il existe x nombre de ces méthodes d'extension de conversion pour la classe 'DataRow', il y en a (x - 1) qui échoueront (plus que probablement) quand ils sont appelés, puisque cette ligne contient un type particulier d'objet. En bref - Méthodes d'extension augmente considérablement le risque d'erreur. Mon argument est que l'un ou l'autre est intrinsèquement risqué, car DataRow peut contenir n'importe quoi. – Pwninstein
Je suis d'accord avec votre argument. Et c'est l'une des raisons pour lesquelles les ORM sont si utiles. – Sorax