Блог

У меня есть веб-служба, которая вернет список, в котором пользователь является DTO. Есть ли какая-либо причина, по которой я не должен определять Person как:

 public class Person {
    public string Name;
    public string Email;
}
  

вместо

 public class Person {
    private string _name;
    public string Name {
      get {
       return _name;
      }
      set {
       _name = value;
      }
   }
}
  

Вторая версия более подробная, и я не вижу никаких причин, по которым общедоступные переменные экземпляра могут быть здесь проблемой. Какая-либо причина, по которой это может быть?

Свойства предпочтительнее полей для поддержки

• привязка; поля не могут быть привязаны
• полиморфизм; вы не можете сделать public virtual string Name;

Вы можете использовать автоматические свойства для уменьшения детализации

 public class Person {
    public string Name { get; set; }
    public string Email { get; set; }
}
  

В целом — это дизайнерское решение — смотрите: http://forums.asp.net/t/1233827.aspx Но реализация DTO немного отличается. Поскольку это всего лишь DTO, и нет поведения без конкретной реализации свойства set / get, вы могли бы с таким же успехом использовать менее подробный метод. Любое изменение реализации не потребует перекомпиляции клиента, поскольку в любом случае они будут сериализованы одинаково через службу, так что ваша меньшая реализация подойдет.

К вашему сведению, если клиент собирается использовать эти классы для привязки к данным, то они должны быть свойствами в классе. Поля не будут привязаны.

В дополнение ко всем другим ответам, свойства позволяют выполнять проверку при чтении или записи свойства. Это потребовало бы больше работы при использовании полей.