DI с Entity Framework Entity

Я хочу добавить класс проверки в Entity, чтобы он мог проверить его действительность перед тем, как быть введенным в базу данных. (Проверка предназначена для бизнес-требований, а не для ограничений db).DI с Entity Framework Entity

У меня есть класс

public class MyEntity 
{ 
    private readonly IValidatorFactory _validatorFactory; 
    public MyEntity(IValidatorFactory validatorFactory) 
    { 
     _validatorFactory = validatorFactory; 
    } 

    //Entity Properties Removed For Clarity 

    public void Validate() 
    { 
     if(_validatorFactory == null) 
     { 
       throw new ArgumentNullException("Validator Factory was null, cannot validate this item"); 
     } 

     var validator = _validatorFactory.GetValidator(this.ItemTypeId); 
     valid = validator.Validate(); 

    } 
}

Использование инъекции зависимостей, я изо всех сил, чтобы увидеть, как я могу чисто устранить зависимость, когда проект использует Ef6. Если я верну DbSet, он, конечно, не будет знать о требовании для валидатора. Требуется конструктор без параметров.

источник

2016-02-23 James

Как правило, это плохая идея использовать инъекции зависимостей в Entitties: http://stackoverflow.com/a/4836790/126014 –

Где вы называете Validate() для этих объектов? –

Validate будет использоваться, когда данные будут импортированы в систему, для чего завод может быть введен, и я мог бы иметь конструктор без параметров для выбора. Проблемы могут возникнуть позже, если сущность будет изменена и обновлена, потребовалось бы вызвать validate() на контроллере, прежде чем разрешить окончательное сохранение. – James

Во-первых, я не думаю, что вы должны пытаться use DI with your entities. Валидация, вероятно, также должна произойти внутри вашего объекта, а не с использованием внешнего валидатора (переданного в метод Validate или созданного с помощью ValidatorFactory).

Entity Framework имеет multiple ways to do validation built in. Вы пробовали их?

Простейшей формой будет добавление атрибутов свойств, таких как Required и StringLength. Для более сложной проверки вы можете реализовать свои объекты IValidateObject или переопределить DbContext.ValidateEntity.

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

источник

2016-02-23 14:58:53 kjbartel

Потребность в внешнем валидаторе ощущается как запах для меня - не говоря уже о запутанном ValidatorFactory.

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

Другая вещь, которая для меня не имеет смысла, состоит в том, что вы идентифицировали 4 объекта с «различных бизнес-требований и правил валидации». ИМО именно там, где вам нужна специфика ad hoc, каждый из которых выполняет свои собственные внутренние правила, в отличие от общности внешней абстракции валидатора.

Что касается подобной части ваших 4 сущностей, то есть данных, я попытался бы извлечь ее в значащее Value Objects и составить ваши объекты этих объектов.

источник

2016-02-23 14:20:53 guillaume31

DI с Entity Framework Entity

ответ

Смежные вопросы