Запах логического кода проверки бизнеса - PullRequest
10 голосов
/ 11 марта 2009

Рассмотрим следующий код:

partial class OurBusinessObject {
    partial void OnOurPropertyChanged() {
        if(ValidateOurProperty(this.OurProperty) == false) {
            this.OurProperty = OurBusinessObject.Default.OurProperty;
        }
    }
}

То есть, когда значение OurProperty в OurBusinessObject изменяется, если значение недопустимо, установите его в качестве значения по умолчанию. Этот шаблон кажется мне запахом кода, но другие здесь (у моего работодателя) не согласны. Что ты думаешь?

Отредактировано, чтобы добавить : меня попросили добавить объяснение, почему это считается нормальным. Идея заключалась в том, что вместо того, чтобы производители бизнес-объекта проверяли данные, бизнес-объект мог проверять свои собственные свойства и устанавливать чистые значения по умолчанию в случаях, когда проверка не удалась. Кроме того, считалось, что если правила проверки изменятся, производителям бизнес-объектов не придется менять свою логику, поскольку бизнес-объект позаботится о проверке и очистке данных.

Ответы [ 14 ]

0 голосов
/ 11 марта 2009

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

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

0 голосов
/ 11 марта 2009

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

0 голосов
/ 11 марта 2009

Вы подтверждаете изменение после того, как оно было сделано? Проверка должна быть выполнена до изменения свойства занятости.

Отвечая на ваши вопросы: решение, представленное в этом фрагменте кода, может вызвать большие проблемы в работе, вы не знаете, появилось ли там значение по умолчанию из-за неверного ввода или просто потому, что что-то другое установило значение по умолчанию

0 голосов
/ 11 марта 2009

Это может или не может "пахнуть", но я больше склоняюсь к "Да, это пахнет".

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

Значит ли установка значения по умолчанию приблизить вас или отвести от функционального описания , описывающего работу приложения?

...