WCF: DataMember приписывают на свойстве по сравнению с участником
Стоит упомянуть
Если вы хотите иметь список всех классов под некоторым пакетом, вы можете использовать Reflection следующим образом:
List<Class> myTypes = new ArrayList<>();
Reflections reflections = new Reflections("com.package");
for (String s : reflections.getStore().get(SubTypesScanner.class).values()) {
myTypes.add(Class.forName(s));
}
Это создаст список классов, которые позже вы можете использовать их по своему усмотрению.
6 ответов
В целом необходимо одобрить применение атрибута DataMember на свойстве, а не на частном поле. Единственная причина применить атрибут к полю вместо этого состоит в том, если свойство было только для чтения (т.е. это не имеет никакого метода set).
Лично я бы просто использовал это свойство и полностью удалил бы переменную-член. т.е.
[DataMember]
public int SomeValue
{ get; set; }
Свойство необъяснимым образом создаст переменную-член за кулисами.
Если добавить [DataMember] в частный int m_SomeValue, этот член не может быть сериализован, поэтому необходимо добавить его в общедоступный int SomeValue.
[DataMember]
private int m_SomeValue;
public int SomeValue {
get {...}
set {...}
}
приведенный выше код не может быть получен клиентом, если вы используете его через WCF.
Есть веские причины, по которым вы можете пометить поля, а не свойства как DataMember.
Пожалуйста, проверьте это для получения дополнительной информации: http://blog.walteralmeida.com/2010/05/wcf-and-datacontract-serialization-internals-and-tips-.html
Кстати: ContractSerializers сериализует любое частное поле, имеющее атрибут DataMemberAttribute , только если оно выполняется в среде полного доверия . Не работает при частичном доверии (решение можно найти в блоге, указанном выше)
Пока Вы используете Name маркер, контракт идентичен независимо от того, используются ли поле или свойство.
[DataMember(Name="SomeValue")]
private int m_SomeValue;
Однако могут быть некоторые проблемы полномочий, получающие доступ к членам парламента, не занимающим официального поста, в особенности на Silverlight и CF - в этом случае я рекомендовал бы использовать общественную собственность в качестве элемента данных. На самом деле я склонялся бы к всегда , используют свойство, если у меня не было очень серьезного основания...
В теории, и, пока Вы сохраняете m_SomeValue всегда равными SomeValue (как простой метод считывания/метод set), ничто. Кроме названия переменной, выставленной WCF. (Очевидно, если Вы отметите m_ переменная, то затем Ваш прокси-класс будет также иметь тот же m_ имя. Прокси-класс генерирует общественную собственность, используете ли Вы общедоступное/защищать/внутреннее/частное поле или свойство.
Однако, если у Вас есть какая-либо специальная логика в Ваших средствах доступа, которые могут изменить возвращенное значение (ToUpper() луг строка, например), затем Вы возвратили бы другое значение.