Постоянные объекты и Depenancy Injection - PullRequest
Новая
       13

Постоянные объекты и Depenancy Injection

3 голосов
/ 28 марта 2012

Существуют ли сценарии, в которых мои POCO должны участвовать в DI.Это запах кода?

1 Ответ

1 голос
/ 28 марта 2012

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

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

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

Редактировать: например: 

public class Customer
{
    public virtual string LastName { get; set; }

    public virtual string FirstName { get; set; }

    public virtual string Ssn { get; set; }
}

public class CustomerValidator
{
    private readonly Customer _customer;

    public CustomerValidator(Customer customer)
    {
        _customer = customer;
    }

    public void FixIfNotValid()
    {
        if (!IsValid())
        {
            _customer.Ssn = "123456789";
            _customer.LastName = "Smith";
        }
    }

    public bool IsValid()
    {
        return !string.IsNullOrEmpty(_customer.Ssn) && !string.IsNullOrEmpty(_customer.LastName);
    }
}

Здесь у вас есть POCO (Клиент) и объект валидатора, которыйодин на POCO отношения с POCO.То есть валидатор инкапсулирует POCO как часть своего состояния и выполняет с ним некоторые (по общему мнению) надуманные операции.

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

У вас есть зависимость, и вы вводите ее здесь.Если позже вы определите наследников Customer, валидатор все равно будет работать с ними.Вы можете проверить свой валидатор, подставив в тестовый двойник POCO.Таким образом, различные мотивы для DI применяются в этом случае так же, как и в случае внедрения сервис-ориентированных классов.Так что лично я не вижу причин, чтобы не вводить.

...