Лучшая практика для возвращения дополнительной информации от Проверить функции

Я бы следовал шаблону методов TryParse и использовал метод с этой сигнатурой:

public bool TryValidate(out IEnumerable<string> errors) { ... }

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

public class EmployeeValidator
{
    public bool IsSatisfiedBy(Employee candidate) 
    { 
        //validate and populate Errors 
    }
    public IEnumerable<string> Errors { get; private set; }
}

Похоже, вам нужен общий класс:

public sealed class ValidationResult<T>
{
    private readonly bool _valid; // could do an enum {Invalid, Warning, Valid}
    private readonly T _result;
    private readonly List<ValidationMessage> _messages;

    public ValidationResult(T result) { _valid = true; _result = result; _messages = /* empty list */; }

    public static ValidationResult<T> Error(IEnumerable<ValidationMessage> messages)
    {
        _valid = false;
        _result = default(T);
        _messages = messages.ToList();
    }

    public bool IsValid { get { return _valid; } }
    public T Result { get { if(!_valid) throw new InvalidOperationException(); return _result; } }
    public IEnumerable<ValidationMessage> Messages { get { return _messages; } } // or ReadOnlyCollection<ValidationMessage> might be better return type

    // desirable things: implicit conversion from T
    // an overload for the Error factory method that takes params ValidationMessage[]
    // whatever other goodies you want
    // DataContract, Serializable attributes to make this go over the wire
}

Вы можете взглянуть на CSLA Rockford Lhotka, в котором есть обширное отслеживание бизнес-правил / проверок для бизнес-объектов.

www.lhotka.net

Мы используем весеннюю проверку вместе с поставщиком ошибок Windows Forms.

Итак, наша функция проверки возвращает словарь с идентификатором элемента управления и сообщением об ошибке (для каждой ошибки проверки). Поставщик ошибок показывает сообщение об ошибке во всплывающем поле рядом с элементом управления, вызвавшим ошибку.

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

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

Таким образом, вы также можете сохранить метод проверки, возвращающий bools.

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

Почему это кажется неуклюжим? Идеально создать подходящий тип для инкапсуляции информации. Однако я бы не обязательно использовал строку для кодирования такой информации. Перечисление может быть более подходящим.

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

Общий шаблон может выглядеть так:

class ValidationInfo {
    public bool Valid { get; private set; }
    public IEnumerable<Failure> Failures { get; private set; }
}

Я согласен с Крисом В. Я задавал те же вопросы, прежде чем читать Rocky's Expert C # Business Objects.

У него блестящий способ обработки правил проверки бизнеса. Проверка выполняется после установки каждого свойства. Каждый раз, когда правило нарушается, состояние объекта становится InValid.

Ваш бизнес-класс может реализовать интерфейс IDataError. Привязка элементов управления пользовательского интерфейса к свойствам бизнес-объекта затем уведомит ваш элемент управления ErrorProvider о любых нарушенных правилах для вашего объекта.

Я действительно рекомендую вам найти время и просмотреть раздел проверки.