Верификации данных в Методе считывания/методе set или в другом месте?
Я знаю, что для этого может быть излишним использовать lib, но для обогащения потока вы можете проверить способ is.js :
is.firefox();
is.ie(6);
is.not.safari();
8 ответов
Ну, один из reaons, почему классы обычно содержат членов парламента, не занимающих официального поста с общедоступными методами считывания/методами set, точно, потому что они могут проверить данные.
Если бы у Вас есть Число, чем может быть между 1 и 100, я определенно поместил бы что-то в метод set, который проверяет это, и затем, возможно, выдайте исключение, которое поймано кодом. Причина проста: Если Вы не делаете этого в методе set, необходимо помнить, что 1 - 100 ограничений каждый раз, когда Вы устанавливаете его, который приводит к дублированному коду или когда Вы забываете это, это приводит к недопустимому состоянию.
Что касается производительности, я с Knuth здесь:
"Мы должны забыть о маленькой эффективности, сказать приблизительно 97% времени: преждевременная оптимизация является корнем всего зла".
@Terrapin, ре:
Если все, что Вы имеете, является набором [простая общественность устанавливала/получала] свойства... они могли бы также быть полями
Свойства имеют другие преимущества перед полями. Они - более явный контракт, они сериализируются, они могут быть отлажены позже, они - хорошее место для расширения посредством наследования. Более неуклюжий синтаксис является случайной сложностью - .net 3.5, например, преодолевает это.
Общее (и испорченный) практика должно запуститься с общедоступных полей и превратить их в свойства позже, на 'по мере необходимости' основание. Это нарушает Ваши условия контракта с любым, кто использует Ваш класс, поэтому лучше запускаться со свойств.
Это зависит.
Обычно код должен перестать работать быстро. Если значение может быть установлено несколькими точками в коде, и Вы проверяете только на после получения значения, ошибка, кажется, находится в коде, который делает обновление. Если методы set проверяют вход, Вы знаете, какой код пытается установить недопустимые значения.
С точки зрения наличия самого удобного в сопровождении кода я думаю, что необходимо сделать столько проверки, сколько Вы можете в методе set свойства. Таким образом, Вы не будете кэшироваться или иначе иметь дело с недопустимыми данными.
В конце концов, это - то, для чего предназначены свойства. Если все, что Вы имеете, является набором свойств как...
public string Name
{
get
{
return _name;
}
set
{
_name = value;
}
}
... они могли бы также быть полями
Вы могли бы хотеть проверить Доменный Управляемый Дизайн Eric Evans. DDD имеет это понятие Спецификации:
... явное подобное предикату ЗНАЧЕНИЕ ВОЗРАЖАЕТ в специализированных целях. СПЕЦИФИКАЦИЯ является предикатом, который определяет, делает ли объект или не удовлетворяет некоторые критерии.
Я думаю, перестав работать, быстро одна вещь, другой то, где сохранить логику для проверки. Домен является правильным местом для хранения логики, и я думаю, Объект Спецификации или проверить метод на Объектах области были бы хорошим местом.
Проверка должна быть получена отдельно от методов считывания или методов set в методе проверки. Тот путь, если проверка должна быть снова использована через несколько компонентов, это доступно.
Когда метод set называют, такой сервис проверки должен быть использован для очистки входа в объект. Тем путем Вы знаете, что вся информация, хранившая в объекте, допустима в любом случае.
Вам не нужен никакой вид проверки для метода считывания, потому что информации об объекте уже доверяют, чтобы быть допустимой.
Не сохраняйте свою проверку до обновления базы данных!! Лучше перестать работать быстро.
Мне нравится реализовывать IDataErrorInfo и помещать мою логику проверки в ее Ошибку и это [columnName] свойства. Тот путь, если Вы хотите проверить программно, существует ли ошибка, которую можно просто протестировать или тех свойств в коде, или можно передать проверку к привязке данных в Веб-формах, Windows Forms или WPF.
Свойство привязки WPF "ValidatesOnDataError" делает это особенно легким.
Я пытаюсь никогда не позволить своим объектам ввести недопустимое состояние, таким образом, методы set определенно имели бы проверку, а также любые методы тем состоянием изменения. Таким образом, я никогда не должен волноваться, что объект, с которым я имею дело, недопустим. Если Вы сохраняете свои методы как границы проверки, то Вы никогда не должны волновать по поводу платформ проверки и IsValid () вызовы метода, опрыснутые повсеместно.