Pourquoi ne WPF en charge la liaison de propriétés d'un objet, mais pas sur des champs?

Liaison généralement ne pas travailler aux champs. La plupart de liaison est basée, en partie, sur la ComponentModel PropertyDescriptor modèle, qui (par défaut) travaille sur propriétés. Cela permet de notifications, validation, etc (rien de ce qui fonctionne avec des champs).

Pour plus de raisons que je ne peux aller dans, les domaines publics sont une mauvaise idée. Ils devraient être des propriétés, en fait. De même, les structures mutables sont un très mauvaise idée. Pas moins, il protège contre les pertes de données imprévues (communément associée avec les structures mutables). Ce doit être une classe:

[DataContract]
public class StatusInfo
{
    [DataMember] public int Total {get;set;}
    [DataMember] public string Authority {get;set;}
}

Il va maintenant se comporter comme vous pensez qu'il devrait. Si vous voulez qu'il soit un immuable struct, ce serait OK (mais de liaison de données serait une façon seulement, bien sûr):

[DataContract]
public struct StatusInfo
{
    [DataMember] public int Total {get;private set;}
    [DataMember] public string Authority {get;private set;}

    public StatusInfo(int total, string authority) : this() {
        Total = total;
        Authority = authority;
    }
}

Cependant, je tiens tout d'abord à la question pourquoi c'est un struct dans la première place. Il est très rare à écrire un struct dans .NET languages. Gardez à l'esprit que la WCF "mex" proxy couche de créer une classe à la consommation de toute façon (sauf si vous utilisez de l'assemblée de partage).

---

En réponse au "pourquoi utiliser les structures" réponse"inconnu (google)"):

Si c'est une réponse à ma question, c'est à tort à de nombreux égards. Tout d'abord, les types de valeur comme variables sont communément attribués (première) sur la pile. Si ils sont poussés dans le tas (par exemple dans un tableau/liste) il n'y a pas beaucoup de différence dans les frais généraux à partir d'une classe - un petit peu de l'objet-tête plus une référence. Les structures doivent toujours être petit. Quelque chose avec de multiples champs de la sur-dimensionné, et la volonté de meurtre de la pile ou de la juste cause de la lenteur en raison de la blitting. En outre, les structures doivent être immuables - unlesss vous vraiment savez ce que vous faites.

Peu près tout ce qui représente un objet doit être immuatable.

Si vous frappez une base de données, la vitesse de la struct vs classe est un non-problème par rapport à une sortie de processus et probablement sur le réseau. Même si il est un peu plus lent, cela ne signifie rien par rapport au point de trouver le juste - à-d. le traitement des objets en tant qu'objets.

Que certaines métriques sur 1M objets:

struct/field: 50ms
class/property: 229ms

basé sur les éléments suivants (la différence de vitesse est dans l'allocation des objets, pas de terrain vs propriété). Donc environ 5x plus lent, mais toujours très, très rapide. Car cela ne va pas être le goulot d'étranglement, ne pas prématurément optimiser cette!

using System;
using System.Collections.Generic;
using System.Diagnostics;
struct MyStruct
{
public int Id;
public string Name;
public DateTime DateOfBirth;
public string Comment;
}
class MyClass
{
public int Id { get; set; }
public string Name { get; set; }
public DateTime DateOfBirth { get; set; }
public string Comment { get; set; }
}
static class Program
{
static void Main()
{
DateTime dob = DateTime.Today;
const int SIZE = 1000000;
Stopwatch watch = Stopwatch.StartNew();
List<MyStruct> s = new List<MyStruct>(SIZE);
for (int i = 0; i < SIZE; i++)
{
s.Add(new MyStruct { Comment = "abc", DateOfBirth = dob,
Id = 123, Name = "def" });
}
watch.Stop();
Console.WriteLine("struct/field: "
+ watch.ElapsedMilliseconds + "ms");
watch = Stopwatch.StartNew();
List<MyClass> c = new List<MyClass>(SIZE);
for (int i = 0; i < SIZE; i++)
{
c.Add(new MyClass { Comment = "abc", DateOfBirth = dob,
Id = 123, Name = "def" });
}
watch.Stop();
Console.WriteLine("class/property: "
+ watch.ElapsedMilliseconds + "ms");
Console.ReadLine();
}
}

OriginalL'auteur Marc Gravell