持久对象和依赖注入

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的各种动机就像在注入面向服务的类时一样。所以，我个人认为没有理由不注射。