Как разделить подтверждение правильности данных от моих простых объектов области (POCOs)?

Я всегда слышу людей аргумент в пользу "Проверения" или метода "IsValid".

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

Таким образом, я предпочитаю "IsValidForNewContract", "IsValidForTermination" или подобный, потому что я полагаю, что большинство проектов заканчивается с несколькими такими блоками проверки допустимости/состояниями в классе. Это также означает, что я не получаю интерфейса, но я могу записать агрегированные блоки проверки допустимости, которые читают, очень хорошо отражают конъюнктуру рынка, которую я утверждаю.

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

Одно решение состоит в том, чтобы иметь DataAccessObject каждого объекта, берут список Блоков проверки допустимости. Когда Сохранение называют, оно формует проверку по сравнению с каждым блоком проверки допустимости:

public class ServiceEndDateValidator : IValidator<Service> {
  public void Check(Service s) {
    if(s.EndDate > s.Contract.EndDate)
      throw new InvalidOperationException();
  }
}

public class ServiceDao : IDao<Service> {
  IValidator<Service> _validators;
  public ServiceDao(IEnumerable<IValidator<Service>> validators) {_validators = validators;}
  public void Save(Service s) {
    foreach(var v in _validators)
      v.Check(service);
    // Go on to save
  }
}

Преимущество, очень ясный SoC, недостаток - то, что мы не получаем проверку, пока Не Сохраняют (), назван.

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

В прошлом я обычно делегировал проверку к сервису к его собственному, такому как ValidationService. Это в принципе все еще реклама слышит к философии DDD.

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

Очень просто, что-то вроде этого в C#

public class ValidationService<T>
{
  private IList<IValidator> _validators;

  public IList<Error> Validate(T objectToValidate)
  {
    foreach(IValidator validator in _validators)
    {
      yield return validator.Validate(objectToValidate);
    }
  }
}

Блоки проверки допустимости могли или быть добавлены в рамках конструктора по умолчанию или введены через некоторый другой класс, такой как ValidationServiceFactory.

Другая возможность состоит в том, чтобы иметь каждую мою реализацию классов

public interface Validatable<T> {
  public event Action<T> RequiresValidation;
}

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

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

Вот другая возможность. Проверка сделана через прокси или декоратора на Объекте области:

public class ServiceValidationProxy : Service {
  public override DateTime EndDate {
    get {return EndDate;}
    set {
      if(value > Contract.EndDate)
        throw new InvalidOperationexception();
      base.EndDate = value;
    }
  }
}

Преимущество: Мгновенная проверка. Может легко быть настроен через МОК.

Недостаток: Если прокси, проверенные свойства должны быть виртуальными, если декоратор все модели предметной области должен быть основан на интерфейсе. Классы проверки закончатся немного тяжеловес - прокси должны наследовать класс, и декораторы должны реализовать все методы. Именование и организация могло бы стать сбивающим с толку.

Мой коллега придумал идею, которая неплохо сработала . Мы так и не придумали для него подходящего названия, но мы назвали его Инспектор / Судья.

Инспектор смотрел на объект и рассказывал вам все правила, которые он нарушал. Судья решит, что с этим делать. Это разделение позволило нам сделать пару вещей. Это позволило нам разместить все правила в одном месте (инспектор), но мы могли бы иметь несколько судей и выбирать судью в зависимости от контекста.

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

У нас также были Судьи, которые были более строгими, поскольку состояние объектов изменялось. Это было заявление на страхование, и во время процесса котировки полис можно было сохранить в незавершенном состоянии. Но как только эта Политика была готова к активации, нужно было установить множество вещей. Таким образом, Цитирующий судья на стороне подачи был не таким строгим, как судья по активации. Тем не менее, правила, используемые в Инспекторе, остались прежними, так что вы все равно могли сказать, что было неполным, даже если вы решили ничего не предпринимать с этим.

В этот момент вы действительно должны остановить процесс.

У нас также были Судьи, которые были более строгими, поскольку состояние объектов изменялось. Это было заявление на страхование, и во время процесса котировки полис можно было сохранить в незавершенном состоянии. Но как только эта Политика была готова к активации, нужно было установить множество вещей. Таким образом, Цитирующий судья на стороне подачи был не таким строгим, как судья по активации. Тем не менее, правила, используемые в Инспекторе, остались прежними, так что вы все равно могли сказать, что было неполным, даже если вы решили ничего не предпринимать с этим.

В этот момент вы действительно должны остановить процесс.

У нас также были Судьи, которые были более строгими, поскольку состояние объектов изменялось. Это была заявка на страхование, и во время процесса котировки полис можно было сохранить в незавершенном состоянии. Но как только эта Политика была готова к активации, нужно было установить множество вещей. Таким образом, Цитирующий судья на стороне подачи был не таким строгим, как судья по активации. Тем не менее, правила, используемые в Инспекторе, остались прежними, так что вы все равно могли сказать, что было неполным, даже если вы решили ничего не предпринимать с этим.

Но как только эта Политика была готова к активации, нужно было установить множество вещей. Таким образом, Цитирующий судья на стороне подачи был не таким строгим, как судья по активации. Тем не менее, правила, использованные в Инспекторе, остались прежними, так что вы все равно могли сказать, что было неполным, даже если вы решили ничего не предпринимать с этим.

Но как только эта Политика была готова к активации, нужно было установить множество вещей. Таким образом, Цитирующий судья на стороне подачи был не таким строгим, как судья по активации. Тем не менее, правила, использованные в Инспекторе, остались прежними, так что вы все равно могли сказать, что было неполным, даже если вы решили ничего не предпринимать с этим.