J'ai la classe suivante:
string pageName = Pages.GetPage("Home");
4 Réponses :
Vous pouvez utiliser ce qui suit:
var field = typeof(Pages).GetField("Home", BindingFlags.Public | BindingFlags.Static); var value = (string)field.GetValue(null);
champ de chaîne = typeof (pages) .getfield ("home"). GetValue (null); juste changé en une ligne et supprimé des liaisons inutiles.
Juste ma tuppence ... Si vous allez utiliser des littéraux ("home"), je voudrais absolument lier le const code>, ie
pages.Le code> ( ils devraient probablement être des constantes dans l'exemple donné). L'approche de réflexion pourrait être pratique si vous avez:
string s = ...something clever...
FieldInfo field = typeof(Pages).GetField(s,
BindingFlags.Static | BindingFlags.Public);
string page = (string)field.GetValue(null);
Vous pouvez le faire comme Konrad suggéré avec réflexion. Mais je considérerais cela beaucoup mieux la conception pour utiliser un dictionnaire et ne pas compter sur la réflexion pour une telle tâche.
public static class Pages { private static readonly IDictionary<String, String> PageMap = null; private static Pages() { Pages.PageMap = new Dictionary<String, String>(); Pages.PageMap.Add("LoggedOut", "LoggedOut.aspx"); Pages.PageMap.Add("Login", "Login.aspx"); Pages.PageMap.Add("Home", "Home.aspx"); } public static GetPage(String pageCode) { String page; if (Pages.PageMap.TryGet(pageCode, out page) { return page; } else { throw new ArgumentException("Page code not found."); } } }
Étant donné que sa classe d'origine a codé de manière rigide les trois propriétés de page, il pourrait alors utiliser une énumération de ces valeurs comme des clés du dictionnaire Pages. aide à éviter les fautes de frappe.
Bon point si la collection de la page est statique (comme le suggère le code d'origine).
Comme d'autres ont dit, j'éviterais d'utiliser la réflexion ici. En outre, bien que cela ajoute un peu plus de code, une énumération pour les noms de page codée est également une bonne idée (également suggérée précédemment)
Au fait, vous vraiment i> doit marquer ces champs
loadonly code> ou utiliser des propriétés en lecture seule.
Const code> doit être évité, si possible, pour que les valeurs ne soient pas d'exécution-constante, mais compilétime. Si vous utilisez des champs privés
const code>, cela ne devrait pas être un problème, mais si vous référenciez un assemblage et utilisez des champs
const code> de l'une des classes de l'assemblage, la valeur est remplacé par la valeur littérale du champ
const code>. Si vous modifiez maintenant la valeur et que vous remplacez simplement l'assemblage référencé sans recompiler l'ensemble de référencement, l'ancienne valeur reste dans l'ensemble de références, qui conduira probablement à un comportement indésirable.