c# - 解决我的服务层中的依赖关系

Question

我在尝试弄清楚如何解决我的架构中的依赖性问题时遇到了麻烦。我正在使用 NHibernate，我正在尝试用我自己的 ICriteriaItem 接口(interface)抽象它的 ICriteria 接口(interface)。 ICriteriaItem 在我的存储库接口(interface)中使用:

ICriteriaItem.cs

public interface ICriteriaItem
{
    string PropertyName { get; set; }
    object Value { get; set; }
}

IUserRepsository.cs

public interface IUserRepository 
{
    IEnumerable<User> Find(IList<ICriteriaItem> criteria);
}

我的服务层在其 AccountService 中使用此存储库

账户服务.cs

public class AccountService : IAccountService
{
    private IUserRepository _userRepo;
    private IRoleRepository _roleRepo;

    public AccountService(IUserRepository userRepository,
        IRoleRepository roleRepository)
    {
        _userRepo = userRepository;
        _roleRepo = roleRepository;
    }

    public ValidateUser(string username, string password)
    {
        password = HashPassword(password);

        _userRepo.Find(new List<ICriteriaItem>() {
            new CriteriaItem() { "Username", username },
            new CriteriaItem() { "Password", password},
        });
    }
}

我的问题是使用 Ninject 获取 CriteriaItem 的实例。我的所有绑定(bind)都在我的 MVC 层中完成，目前，我的服务层对 Ninject 一无所知。我的服务已经注入(inject)到构造函数中。所以这是我的选择:

1. 我可以将 ICriteriaItem 注入(inject)到构造函数中。这感觉很脏，因为每个服务都会注入(inject)它。我确信我可以使用基本存储库来做到这一点，但它仍然感觉很脏。

2. 注入(inject)我的内核并在我的服务中使用它来获取 ICriteriaItem 的实例。感觉更糟。

3. 只需公开 ICriteriaItem 的具体类并取消接口(interface)。

4. 另辟蹊径...

想法？我做错了吗？有没有更好的办法？我在这里缺少什么？

Answer 1

CriteriaItem 是一个数据传输对象。 DTO 永远不应有任何依赖关系，因此不应使用 Nnject 创建它们。当前的实现就像它应该的那样。