Проверка данных в Getter/Setter или где-то еще?

Ну, одна из причин, почему классы обычно содержат закрытые члены с открытыми геттерами/сеттерами, заключается именно в том, что они могут проверять данные.

Если у вас есть число, которое может быть между 1 и 100, я бы определенно поместил что-то в setter, что подтверждает это, а затем, возможно, выбросил исключение, которое перехватывается кодом. Причина проста: если вы не делаете этого в setter, вы должны помнить, что ограничение от 1 до 100 каждый раз, когда вы устанавливаете его, что приводит к дублированию кода или когда вы забываете его, это приводит к недопустимому состоянию.

Что касается исполнения, то я здесь с кнутом:

"Мы должны забыть о малой эффективности, скажем о 97% времени: преждевременная оптимизация-это корень всех зол."

@Terrapin, заново:

Если все, что у вас есть, это куча [простых публичные set/get] свойства ... они с тем же успехом это могут быть поля

Свойства имеют и другие преимущества перед полями. Они являются более явным контрактом, они сериализованы, их можно отладить позже, они являются хорошим местом для расширения через наследование. Более неуклюжий синтаксис является случайной сложностью - .net 3.5, например, преодолевает это.

Распространенная (и ошибочная) практика заключается в том, чтобы начать с общедоступных полей, а затем превратить их в свойства на основе 'as needed'. Это нарушает ваш контракт с любым, кто потребляет ваш класс,поэтому лучше всего начать с свойств.

С точки зрения наличия наиболее поддерживаемого кода, я думаю, что вы должны сделать как можно больше проверок в setter свойства. Таким образом, вы не будете кэшировать или иным образом иметь дело с недопустимыми данными.

В конце концов, именно для этого и предназначены свойства. Если все, что у вас есть, это куча таких свойств, как...

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

с таким же успехом они могли бы быть полями

Это зависит.

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

Валидация должна быть записана отдельно от геттеров или сеттеров в методе валидации. Таким образом, если проверка должна быть повторно использована в нескольких компонентах, она доступна.

Когда вызывается setter, такая служба проверки должна использоваться для очистки входных данных в объект. Таким образом, вы знаете, что вся информация, хранящаяся в объекте, действительна в любое время.

Вам не нужна никакая проверка для getter, потому что информация об объекте уже считается достоверной.

Не сохраняйте валидацию до обновления базы данных!! Лучше потерпеть неудачу быстро .

Возможно , вы захотите проверить доменный дизайн, разработанный Эриком Эвансом. DDD имеет это понятие спецификации: ...

явный предикат-как VALUE OBJECTS для специальных целей. Один SPECIFICATION-это предикат, который определяет, делает ли объект это или нет не удовлетворяет некоторым критериям.

Я думаю, что быстрая неудача-это одно,а другое-где хранить логику для проверки. Домен-это правильное место для хранения логики, и я думаю, что объект спецификации или метод проверки для ваших объектов домена будет хорошим местом.

Мне нравится реализовывать IDataErrorInfo и помещать свою логику проверки в ее свойства Error и this[columnName]. Таким образом, если вы хотите проверить программно, есть ли ошибка, вы можете просто проверить любое из этих свойств в коде, или вы можете передать проверку привязке данных в веб-формах, формах Windows или WPF.

Свойство привязки WPF's "ValidatesOnDataError" делает это особенно легким.

Я стараюсь никогда не позволять моим объектам входить в недопустимое состояние, поэтому у сеттеров определенно будет проверка, а также любые методы, которые изменяют состояние. Таким образом, мне никогда не придется беспокоиться о том, что объект, с которым я имею дело, недействителен. Если вы сохраняете свои методы в качестве границ проверки, то вам никогда не придется беспокоиться о фреймворках проверки и вызовах метода IsValid(), разбросанных повсюду.