Бизнес-объекты, валидация и исключения

Как Paul Stovell упомянутая статья , можно реализовать безошибочную проверку в бизнес-объектах путем реализации интерфейса IDataErrorInfo. Выполнение так позволит пользовательское уведомление об ошибке ErrorProvider WinForm и WPF's, связывающий с правилами проверки . Логика для проверки свойств объектов хранится в одном методе, вместо в каждом из методов get свойства, и необходимо не обязательно обратиться к платформам как Блок приложений Проверки или CSLA.

До того, чтобы мешать пользователю изменить фокус из текстового поля затронут: В первую очередь, это обычно - не лучшая практика. Пользователь может хотеть заполнить форму не в порядке, или, если правило проверки зависит от результатов нескольких средств управления, пользователю, вероятно, придется заполнить фиктивное значение только для выхода из одного управления для установки другого управления. Однако это может быть реализовано путем установки свойства Form's AllowValidate на его значение по умолчанию, EnableAllowFocusChange и подписки на Управление. Событие Validating:

    private void textBox1_Validating(object sender, CancelEventArgs e)
    {
        if (textBox1.Text != String.Empty)
        {
            errorProvider1.SetError(sender as Control, "Can not be empty");
            e.Cancel = true;
        }
        else
        {
            errorProvider1.SetError(sender as Control, "");
        }
    }

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

Вы хотите пахать немного в замечательной работе Paul Stovell относительно подтверждения правильности данных. Он подвел итог своих идей когда-то в эта статья . Я, оказывается, совместно использую его точку зрения по вопросу, который я реализовал в мои собственные библиотеки .

Вот, в словах Paul, недостатках к выдаванию исключения в методах set (на основе образца, где Name свойство не должно быть пустым):

• могут быть времена, где у Вас на самом деле должно быть пустое название. Например, как значение по умолчанию для "Создают учетную запись" форма.
• при доверии этому для проверки каких-либо данных перед сохранением, Вы пропустите случаи, где данные уже недопустимы. Этим я имею в виду, если Вы загружаете учетную запись из базы данных с пустым названием и не изменяете ее, Вы никогда не могли бы знать, что это было недопустимо.
• , Если Вы не используете привязку данных, необходимо записать много кода с try/catch блоки, чтобы показать эти ошибки пользователю. При попытке показать ошибки на форме, поскольку пользователь заполняет его, становится очень трудным.
• мне не нравится выдавать исключения для неисключительных вещей. Пользователь, определяющий имя учетной записи к , "Supercalafragilisticexpialadocious" не является исключением, это - ошибка. Это - конечно, персональная вещь.
• Это делает очень трудным получить список всех правил, которые были нарушены. Например, на некоторых веб-сайтах, Вы будете видеть сообщения проверки такой, поскольку "Имя должно быть введено. Адрес должен быть введен. Электронная почта должна быть введена" . Для отображения этого Вы собираетесь нуждаться в большом количестве из try/catch блоки.

И вот основные правила для альтернативного решения:

1. нет ничего неправильно с наличием недопустимого бизнес-объекта, пока Вы не пытаетесь сохранить его.
2. Любой и все нарушенные правила должны быть восстановимы от бизнес-объекта, так, чтобы привязка данных, а также Ваш собственный код, видела, существуют ли ошибки и обрабатывают их соответственно.

Я склонен полагать, что бизнес-объекты должны выдать исключения, когда переданные значения, которые нарушают его бизнес-правила. Однако кажется, что архитектура winforms 2.0 привязки данных принимает противоположное и таким образом, большинство людей является направляющей-roaded в поддержку этой архитектуры.

я соглашаюсь с последним ответом shabbyrobe, что бизнес-объекты должны быть созданы, чтобы быть применимыми и работать правильно в нескольких средах и не только среде winforms, например, бизнес-объект мог использоваться в веб-сервисе типа SOA, интерфейсе командной строки, asp.net, и т.д. Объект должен вести себя правильно и защитить себя от недопустимых данных во всех этих случаях.

аспект, который часто пропускается, также, что происходит в управлении сотрудничеством между объектами в 1-1, 1-n или n-n отношения, должны они также принимать добавление недопустимых сотрудников и просто поддержите недопустимый флаг состояния, который должен быть проверен или если это активно отказывается добавлять недопустимое сотрудничество. Я должен признать, что я в большой степени под влиянием подхода Оптимизированного объектного моделирования (SOM) Jill Nicola и др., Но что еще логично.

следующая вещь состоит в том, как работать с формами окон. Я смотрю на создание обертки UI для бизнес-объектов для этих сценариев.

Вы рассмотрели генерирование события в методе set, если данные недопустимы? Это избежало бы проблемы выдачи исключения и избавит от необходимости явно проверять объект на "недопустимый" флаг. Вы могли даже передать аргумент, указывающий, какое поле привело проверку к сбою, для создания его более допускающим повторное использование.

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

Я всегда был поклонником подхода Rocky Lhotka в платформа CSLA (как упомянуто Charles). В целом, ли это управляется методом set, или путем вызова явного Проверяют метод, набор объектов BrokenRule сохраняется внутренне бизнес-объектом. UI просто должен проверить метод IsValid на объекте, который в свою очередь проверяет число BrokenRules, и обработайте его соответственно. С другой стороны, у Вас мог легко быть Проверить метод, генерируют событие, которое UI мог обработать (вероятно, более чистый подход). Можно также использовать список BrokenRules для отображения сообщений об ошибках к использованию или в сводной форме или рядом с соответствующим полем. Хотя платформа CSLA записана в.NET, общий подход может использоваться на любом языке.

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

Между прочим, мне никогда не нравилась идея не разрешения пользовательскому отпуску поле, когда это находится в недопустимом состоянии. Существует столько ситуаций, где Вы, возможно, должны были бы покинуть поле временно (возможно, для установки некоторого другого поля сначала) перед возвращением и фиксацией недопустимого поля. Я думаю, что это - просто ненужное неудобство.

Предположение, что Вы имеете отдельную проверку и сохраняетесь (т.е. сохраняет к базе данных), код, я сделал бы следующее:

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

2. Ваша база данных сохраняет код, должен выдать исключения недействительного аргумента для неправильных данных. Имеет смысл делать это здесь, так как Вы не можете возобновить запись базы данных в этой точке. Идеально этого никогда не должно происходить, так как UI должен препятствовать тому, чтобы пользователь сохранил, но Вам все еще нужен он для обеспечения непротиворечивости базы данных. Также Вы могли бы называть этот код от чего-то другого, чем UI (например, пакетные обновления), где нет никакого подтверждения правильности данных UI.

Вы могли бы хотеть переместить проверку за пределами методов get и методов set. У Вас могли быть функция или свойство под названием IsValid, который выполнит все правила проверки. t заполнил бы словарь или хеш-таблицу со всеми "Нарушенными Правилами". Этот словарь был бы представлен внешнему миру, и можно использовать его для заполнения сообщений об ошибках.

Это - подход, который проявлен в CSLA.Net.

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

Каждый открытый метод должен проверить свои исходные данные и "ArgumentException" s броска, когда они являются неправильными. (И закрытые методы должны проверить свои исходные данные с "Отладкой. Утверждайте () "s для упрощения разработки, но это - другая история.) Это правило о проверке исходных данных к открытым методам (и свойства, конечно) верно для каждого слоя приложения.

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

, В то время как правила, данные выше, никогда не должны почти нарушаться, иногда проверка бизнес-объекта может быть очень сложной, и та сложность не должна быть навязана на UI. В этом случае для интерфейса Филиала хорошо позволить войти некоторому дрейфу, что это принимает, и затем предусмотрите явное, Проверяют (строка []) предикат, чтобы проверить свойства и дать обратную связь на какой потребности быть измененным. Но заметьте в этом случае, что существуют все еще четко определенные интерфейсные требования, и никакие исключения не должны когда-либо быть выданными (предположение, что код вызова следует правилам).

После этой последней системы, я почти никогда не делаю раннюю проверку на методах set свойства, так как это мягкое - усложняет использование свойств, (но в случае, данном в вопросе, я мог бы). (Как в стороне, не препятствуйте тому, чтобы я снабдил вкладками из поля просто, потому что оно имеет неправильные данные в нем. Я получаю clausterphobic, когда я не могу снабдить вкладками вокруг формы! Я возвращусь и зафиксирую его через минуту, я обещаю! Хорошо, я чувствую себя лучше теперь, извините.)

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

Рассматривают многоярусное заявление и требования/средства проверки каждого слоя. Средний слой, Объект, является тем, который, кажется, подлежит дебатам здесь.

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

• Объект
  ?

• ASP.NET/Windows Forms
  защищает состояние формы (не объект) использование стандартных программ блока проверки допустимости и/или управляет без исключения использования (winforms не поставлются с блоками проверки допустимости, но существует превосходный ряд в msdn , описывающем, как реализовать их )

, Говорят, что у Вас есть таблица со списком гостиничных номеров, и каждая строка имеет столбец для количества кроватей, названных 'кроватями'. Самый разумный тип данных для того столбца является неподписанным маленьким integer*. У Вас также есть простой объект OLE с Int16* свойство под названием 'Кровати'. Проблема - то, что можно придерживаться-4555 в Int16, но когда Вы идете для сохранения данных к базе данных, Вы собираетесь получить Исключение. Который прекрасен - моей базе данных нельзя позволить сказать, что гостиничный номер имеет меньше, чем нулевые кровати, потому что гостиничный номер не может иметь меньше, чем нулевые кровати.

*, Если Ваша база данных может представить его, но позволять нам принять его, может
*, я знаю, что можно просто использовать ushort в C#, но в целях этого примера, давайте предположим, что Вы не можете

существует некоторый беспорядок относительно того, должны ли объекты представить Ваше предприятие, или должны ли они представить состояние Вашей формы. Конечно, в ASP.NET и Windows Forms, форма совершенно способна к обработке и проверке ее собственного состояния. Если у Вас есть текстовое поле на форме ASP.NET, которая будет используемой для заполнения того же самого поля Int16, Вы, вероятно, поместили управление RangeValidator на своей странице, которая тестирует вход, прежде чем это будет присвоено Вашему объекту. Это препятствует тому, чтобы Вы ввели значение меньше, чем нуль, и вероятно препятствует тому, чтобы Вы ввели значение, больше, чем, скажем, 30, которого, надо надеяться, было бы достаточно для питания худший наполненный блохой хостел, который можно вообразить. На обратной передаче Вы, вероятно, проверили бы свойство IsValid страницы прежде здание Ваш объект, таким образом, предотвращение Вашего объекта от когда-либо представления меньше, чем нулевые кровати и предотвращение Вашего метода set от того, чтобы когда-нибудь быть названным со значением, которое это не должно содержать.

, Но Ваш объект все еще способны из представления меньше, чем нулевые кровати, и снова, если Вы использовали объект в сценарии, не включающем слои, которым интегрировали проверку в них (Ваша форма и Ваш DB), Вы являетесь неудачливыми.

, Почему Вы когда-либо были бы в этом сценарии? Это должно быть симпатичное исключительный стечение обстоятельств! Ваш метод set поэтому должен выдать исключение, когда он получает недопустимые данные. Это никогда не должно бросаться, но это могло быть. Вы могли писать Windows Form для управления объектом заменить форму ASP.NET и забыть проверять диапазон прежде, чем заполнить объект. Вы могли использовать объект в запланированной задаче, где нет никакого взаимодействия с пользователем вообще, и который сохраняет к различному, но связанный, область базы данных, а не таблицы, на которую отображается объект. В последнем сценарии Ваш объект может ввести состояние, где это недопустимо, но Вы не будете знать, пока результаты других операций не начнут затрагиваться недопустимым значением. Если Вы проверяете на них и выдаете исключения, который является.

Если бы вход идет вне бизнес-правила, реализованного бизнес-объектом, я сказал бы, что это - случай, не обработанный бизнес-объектом. Поэтому я выдал бы исключение. Даже при том, что метод set "обработал" бы 5 в Вашем примере, бизнес-объект не будет.

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

, По-моему, необходимо будет решить, какой способ пойти в зависимости от сложности позволил/запретил вход.

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

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

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

[MinValue(10), MaxValue(20)]
public int Value { get; set; }

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

По моему опыту, правила проверки редко универсальны через все экраны/формы/процессы в приложении. Сценарии как это распространены: на добавить странице это может быть хорошо для объекта Человека не иметь фамилию, но на странице редактирования это должно иметь фамилию. При этом я приехал, чтобы полагать, что проверка должна произойти за пределами объекта, или правила должны быть введены в объект, таким образом, правила могут измениться, учитывая контекст. Допустимый/Недопустимый должно быть явное состояние объекта после проверки или той, которая может быть получена путем проверки набора на неудавшиеся правила. Неудавшееся бизнес-правило не является исключением, по моему скромному мнению.

Выдача исключения в Вашем случае прекрасна. Можно считать случай истинным исключением, потому что что-то пытается установить целое число на строку (например). Отсутствие бизнес-правил knowledege Ваших представлений означает, что они должны считать этот случай исключительным и возврат что назад к представлению.

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

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

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

Вы хотели бы рассматривать подход взятый платформой Spring . При использовании Java (или.NET), можно использовать Spring как есть, но даже если Вы не, Вы могли бы все еще использовать тот шаблон; необходимо было бы просто записать собственную реализацию его.

Я определенно защитил бы и клиент и проверку серверной стороны (или проверяющий на различных слоях). Это особенно важно при передаче через физические уровни или процессы, поскольку стоимость выдает исключения, становится все больше дорогим. Кроме того, чем далее вниз цепочка Вы ожидаете проверки, тем больше времени потрачено впустую.

для использования Исключений или не для подтверждения правильности данных. Я думаю, что нормально использовать исключение в процессе (хотя все еще предпочтительный), но за пределами процесса, назовите метод для проверки бизнес-объекта (например, прежде, чем сохранить) и иметь метод возвращают успех операции наряду с любой проверкой ошибки . Ошибки не являются' исключительными.

Microsoft выдает исключения от бизнес-объектов, когда проверка перестала работать. По крайней мере, это - то, как Блок приложений Проверки Библиотеки Предприятия работает.

using Microsoft.Practices.EnterpriseLibrary.Validation;
using Microsoft.Practices.EnterpriseLibrary.Validation.Validators;
public class Customer
{
  [StringLengthValidator(0, 20)]
  public string CustomerName;

  public Customer(string customerName)
  {
    this.CustomerName = customerName;
  }
}

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

Примечание, которое вот различие между определением правил проверки и применением их. Вы могли бы хотеть определить (т.е. кодировать или аннотировать) Ваши бизнес-правила в Вашем слое бизнес-логики, но вызвать их от UI так, чтобы они могли обработанный способом, соответствующим тому конкретному UI. Способ обработки будет варьироваться для различного UI, например, основанные на форме веб-приложения по сравнению с ajax веб-приложениями. Проверка исключения на наборе предлагает очень ограниченные опции для обработки.

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

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

На мой взгляд, большинство людей пытаются делать слишком много (взаимодействовать с представлениями, сохранять данные в базе данных и т. Д.) С объектами предметной области, но иногда вам нужно больше уровней и лучшее разделение проблем, т. Е. Один или несколько Просмотреть модели. Затем вы можете применить проверку без исключений к вашей модели представления (проверка может быть разной для разных контекстов, например, веб-сервисов / веб-сайта и т. Д.) И сохранить проверки исключений внутри своей бизнес-модели (чтобы модель не была повреждена). Вам понадобится один (или несколько) слоев Application Service, чтобы сопоставить вашу модель представления с вашей бизнес-моделью.