2010-11-19 6 views
2

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?

+0

Qu'est-ce que la personne qui a dit être dangereuse a dit qu'elle était dangereuse pour elle? – Sorax

+0

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

+0

Je suis d'accord avec votre argument. Et c'est l'une des raisons pour lesquelles les ORM sont si utiles. – Sorax

Répondre

1

Je ne vois rien de dangereux à faire cela; Tant que vous avez le contrôle sur l'ensemble du code et la mise en page de votre DataSet ne va pas être changé en dessous de vous. Cela semble exactement comme le genre de choses pour lesquelles les méthodes d'extension ont été conçues.

Je serais curieux d'entendre le raisonnement derrière la déclaration que c'était une utilisation «dangereuse».

1

Si vous placez les méthodes d'extension dans une bibliothèque spécifique à votre projet, vous ne risquez pas de souder d'autres projets avec vos extensions très spécifiques. Je ne vois pas comment c'est dangereux non plus.

MISE À JOUR: D'accord, je comprends votre point, @Pwninstein: le DataRow que vous appelez l'extension sur pourrait très bien être QUOI QUE CE SOIT. Cependant, ayant une méthode qui prend un DataRow comme argument pour faire votre objet est pas plus dangereux.

2

Extension methods ne sont pas plus ou moins dangereux que de faire une méthode static parce que extension methods compiler à des méthodes statiques. Ils ne sont que du sucre syntaxique pour le bénéfice des programmeurs. Vous pouvez comparer le IL par vous-même mais voici un article avec un exemple qui pourrait vous aider à convaincre votre collègue extension methods ne sont pas dangereux: How do Extension Methods work?