Дизайн библиотеки классов CRUD для возврата полезных сообщений о сбое бизнес-логики, что не является исключительным

по соображениям производительности первоначальная проверка ввода должна выполняться на уровне клиента. (т. е.: не беспокойтесь о отправке плохих данных по проводу.) На клиентском уровне сбой проверки ввода фактически будет очень ожидаемой проблемой, которая не должна создавать исключения. Однако если вы поместите эту "раннюю" проверку на уровень клиента, сбой проверки данных, обнаруженный на любом более глубоком уровне, можно разумно рассматривать как непредвиденную проблему, поэтому создание исключений для данных ошибки проверки на этих уровнях не будут неуместными.

вы можете найти это сообщение в блоге Роба Бэгби интересным; он описывает, как реализовать репозиторий для обработки операций CRUD, и, на ваш взгляд, в частности, как реализовать проверку, возвращая коллекцию "RuleViolation" клиенту в случае возникновения проблемы.

http://www.robbagby.com/silverlight/patterns-based-silverlight-development-part-ii-repository-and-validation/

[edit] для меня это случай для создания исключения: если для создания пользователя требуется имя, а имя не указано, вызывающий не использовал правильные аргументы и не использует метод по назначению. InvalidArgumentException звучит адекватно.

вы действительно должны проверить реализацию правил проверки Rocky Lhotka в его CSLA framework.

Примечание: Я не скажем, использовать его фреймворк в массовом порядке, так как у него есть некоторые проблемы с соединением, которые нарушают некоторые усилия SRP в последних тенденциях развития .NET.

но его структура использует "автоматическое" уведомление до уровня пользовательского интерфейса и интеграцию с сообщениями об ошибках проверки с поддержкой Элементы управления Web/Winforms.

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

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

public class Response<T> where T:BusinessObject
{
    public Response(T oldOriginalValue, T newValue)
    {
    }

    /// <summary>
    /// List of Validation Messages
    /// </summary>
    public List<ValidationMessage> ValidationMessages { get; set; }

    /// <summary>
    /// Object passed into the CRUD method
    /// </summary>
    public T OldValue { get; private set; }

    /// <summary>
    /// Object passed back from the CRUD method, with values of identity fields, etc populated
    /// </summary>
    public T NewValue { get; private set; }

    /// <summary>
    /// Was the operation successful
    /// </summary>
    public bool Success { get; set; }
}

public class ValidationMessage
{
    /// <summary>
    /// Property causing validation message (i.e. FirstName)
    /// </summary>
    string Property { get; set; }

    /// <summary>
    /// Validation Message text
    /// </summary>
    string Message { get; set; }
}

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

Если библиотеке предлагается создать объект пользователя, но не может, потому что имя пользователя не удалось проверить, вы можете передать обратно пустой пользователь вместе с сообщениями об ошибке проверки и надеяться, что клиентский код проверяет возвращаемое значение. Мой опыт (DCOM pre ATL flashbacks) с необходимостью тестирования возвращаемых значений для кодов ошибок заключается в том, что легко успокоиться (или лениво) и пропустить его.

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