Depuis il semble y avoir beaucoup de confusion en ce qui concerne la façon dont la pile des cadres et des méthodes de travail, voici une démonstration simple:
static void Main(string[] args)
{
MyClass c = new MyClass();
c.Name = "MyTest";
Console.ReadLine();
}
class MyClass
{
private string name;
void TestMethod()
{
StackTrace st = new StackTrace();
StackFrame currentFrame = st.GetFrame(1);
MethodBase method = currentFrame.GetMethod();
Console.WriteLine(method.Name);
}
public string Name
{
get { return name; }
set
{
TestMethod();
name = value;
}
}
}
La sortie de ce programme sera:
set_Name
Propriétés en C# sont une forme de sucre syntaxique. Ils dressent vers le bas pour les getter et setter dans l'ILLINOIS, et il est possible que certains .NET langues pourraient même ne pas les reconnaître comme des propriétés de la propriété de la résolution se fait entièrement à la convention, il n'y a pas vraiment de règles dans le IL spec.
Maintenant, disons pour le moment que vous avez eu une très bonne raison pour qu'un programme voulez examiner, à sa propre pile (et il y a fort peu de raisons pratiques pour le faire). Pourquoi dans le monde voudriez-vous qu'il se comporte différemment pour les propriétés et les méthodes?
La logique derrière les attributs, c'est qu'ils sont une sorte de méta-données. Si vous souhaitez un comportement différent, le code dans l'attribut. Si un attribut peut signifier deux choses différentes selon qu'il est appliqué à une méthode ou une propriété, alors vous devriez avoir deux attributs. Définir la cible sur le premier AttributeTargets.Method et la seconde à l' AttributeTargets.Property. Simple.
Mais encore une fois, en marchant votre propre pile de ramasser quelques attributs à partir de la méthode d'appel est dangereux, au mieux. Dans un sens, vous êtes le gel de votre conception du programme, ce qui rend beaucoup plus difficile pour quelqu'un d'étendre ou de refactoriser. Ce n'est pas la manière dont les attributs sont normalement utilisés. Un de plus... approprié exemple, serait quelque chose comme une validation de l'attribut:
public class Customer
{
[Required]
public string Name { get; set; }
}
Ensuite, votre validateur de code, qui ne sait rien à propos de l'entité réelle qui est passée, peut faire ceci:
public void Validate(object o)
{
Type t = o.GetType();
foreach (PropertyInfo prop in
t.GetProperties(BindingFlags.Instance | BindingFlags.Public))
{
if (Attribute.IsDefined(prop, typeof(RequiredAttribute))
{
object value = prop.GetValue(o, null);
if (value == null)
throw new RequiredFieldException(prop.Name);
}
}
}
En d'autres termes, vous êtes en examinant les attributs d'une instance qui a été donnée à vous , mais que vous n'avez pas nécessairement au courant de rien sur le type de. Attributs XML, Contrat de Données d'attributs, de même Attribut les attributs de presque tous les attributs dans le .NET Framework sont utilisés de cette manière, de mettre en œuvre certaines des fonctionnalités dynamiques sur le type de l'instance , mais non à l'égard de l' état du programme ou de ce qui arrive à être sur la pile. Il est très peu probable que vous êtes réellement dans le contrôle de ce au moment où vous créez la trace de la pile.
Donc, je vais vous recommander à nouveau que vous n'avez pas utiliser la pile-la marche d'approche à moins d'avoir une très bonne raison de le faire, qui ne vous ont pas dit que nous encore. Sinon, vous êtes susceptible de trouver vous-même dans un monde de souffrance.
Si vous devez absolument (ne dites pas que nous ne vous avais pas prévenu), puis utiliser deux attributs, que l'on peut appliquer les méthodes et qui peuvent s'appliquer aux propriétés. Je pense que vous trouverez que beaucoup plus facile à travailler que d'un seul super-attribut.
