Question

我的POCO是否应该参与DI。这是代码味道吗？。

Answer 1

我认为代码味道表明某些事情可能是错误的，但并不一定是错的。我不知道这会上升到那个水平。

想象一下，您有一个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（即构造函数依赖注入）的方式编写代码。忽略这个例子的惯用性，我不认为这是代码气味。

你有一个依赖，你在这里注入它。如果以后，您定义的继承者客户，验证者仍将继续使用它们。您可以通过替换POCO的测试双重来测试您的验证器。因此，在这种情况下，DI的各种动机适用于注入面向服务的类的情况。所以，就个人而言，我认为没有理由不注射。

持久对象和依赖注入

1 个答案: