[ACCEPTED]-Why does WPF support binding to properties of an object, but not fields?-field

Binding generally doesn't work to fields. Most binding 45 is based, in part, on the ComponentModel 44 PropertyDescriptor model, which (by default) works on properties. This 43 enables notifications, validation, etc (none 42 of which works with fields).

For more reasons 41 than I can go into, public fields are a 40 bad idea. They should be properties, fact. Likewise, mutable 39 structs are a very bad idea. Not least, it protects 38 against unexpected data loss (commonly associated 37 with mutable structs). This should be a 36 class:

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

It will now behave as you think it 35 should. If you want it to be an immutable struct, that 34 would be OK (but data-binding would be one-way 33 only, of course):

[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;
    }
}

However, I would first 32 question why this is a struct in the first 31 place. It is very rare to write a struct in .NET 30 languages. Keep in mind that the WCF "mex" proxy 29 layer will create it as a class at the consumer 28 anyway (unless you use assembly sharing).

In 27 answer to the "why use structs" reply ("unknown 26 (google)"):

If that is a reply to my question, it 25 is wrong in many ways. First, value types 24 as variables are commonly allocated (first) on the stack. If 23 they are pushed onto the heap (for example 22 in an array/list) there isn't much difference 21 in overhead from a class - a small bit of 20 object header plus a reference. Structs 19 should always be small. Something with multiple 18 fields will be over-sized, and will either 17 murder your stack or just cause slowness 16 due to the blitting. Additionally, structs 15 should be immutable - unlesss you really know 14 what you are doing.

Pretty much anything 13 that represents an object should be immuatable.

If 12 you are hitting a database, the speed of 11 struct vs class is a non-issue compared 10 to going out-of-process and probably over 9 the network. Even if it is a bit slower, that 8 means nothing compared to the point of getting 7 it right - i.e. treating objects as objects.

As 6 some metrics over 1M objects:

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

based on the 5 following (the speed difference is in object 4 allocation, not field vs property). So about 3 5x slower, but still very, very quick. Since this is not 2 going to be your bottleneck, don't prematurely 1 optimise this!

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();
    }
}

I can only guess why they only support properties: perhaps 9 because it seems to be a universal convention 8 in the .NET framework never to expose mutable 7 fields (probably to safeguard binary compatibility), and they somehow expected all 6 programmers to follow the same convention.

Also, although 5 fields and properties are accessed with 4 the same syntax, data binding uses reflection, and 3 (so I've heard) reflection must be used 2 differently to access fields than to access 1 properties.