Binding обычно не работает с полями. Большая часть привязки основана частично на модели ComponentModel PropertyDescriptor, которая (по умолчанию) работает со свойствами. Это позволяет уведомления, проверки и т. Д. (Ни один из которых не работает с полями).
По большим причинам, чем я могу описать, публичные поля - плохая идея. Это должны быть свойства, факт. Точно так же изменяемые структуры - очень плохая идея. Не в последнюю очередь, он защищает от неожиданной потери данных (обычно связанных с изменчивыми структурами). Это должен быть класс:
[DataContract]
public class StatusInfo
{
[DataMember] public int Total {get;set;}
[DataMember] public string Authority {get;set;}
}
Теперь он будет вести себя так, как вы думаете. Если вы хотите, чтобы это была структура immutable , это было бы нормально (но привязка данных была бы только односторонней, конечно):
[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;
}
}
Однако я бы сначала спросил, почему это структура в первую очередь. очень редко писать структуру на языках .NET. Имейте в виду, что прокси-слой WCF "mex" все равно создаст его как класс у потребителя (если только вы не используете совместное использование сборок).
В ответ на вопрос «зачем использовать структуры» («неизвестно (google)»):
Если это ответ на мой вопрос, он во многих отношениях неверен. Во-первых, типы значений в качестве переменных обычно выделяются (сначала) в стеке. Если они помещаются в кучу (например, в массиве / списке), нет больших отличий в накладных расходах от класса - маленький кусочек заголовка объекта плюс ссылка. Структуры всегда должны быть маленькими . Что-то с несколькими полями будет слишком большого размера и либо убьет ваш стек, либо просто вызовет медлительность из-за блинта. Кроме того, структуры должны быть неизменными - если только вы действительно не знаете, что делаете.
Практически все, что представляет объект, должно быть неизменным.
Если вы работаете с базой данных, скорость struct vs class не является проблемой по сравнению с выходом из процесса и, возможно, по сети. Даже если это немного медленнее, это ничего не значит по сравнению с тем, как это сделать правильно - то есть обрабатывать объекты как объекты.
Так как некоторые показатели более 1M объектов:
struct/field: 50ms
class/property: 229ms
на основании следующего (разница в скорости заключается в распределении объектов, а не в свойствах поля и свойства). Так что примерно в 5 раз медленнее, но все же очень, очень быстро . Поскольку это не будет вашим узким местом, не оптимизируйте это преждевременно!
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();
}
}