Dependency injection 持久对象与依赖注入

是否存在我的POCO应该参与DI的场景。这是一种代码气味吗？

我认为代码气味是一种可能出错但不一定出错的迹象。我不知道这会上升到那个水平

假设您有一个客户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，validator对象就没有意义，因此您编写代码的方式必然会迫使客户端提供POCO（即构造函数依赖项注入）。忽略这个例子的人为性质，我不会认为这是一种代码气味。 你有一个依赖项，你把它注射到这里。如果稍后，您将定义的继承者 客户，验证程序仍将对其进行处理。您可以通过替换POCO的测试双精度来测试验证器。因此，DI的各种动机在本例中适用，就像它们在注入面向服务的类时一样。所以，就我个人而言，我认为没有理由不注射。

当你说POCO时，“C”指的是C吗？可能是