何时何地进行依赖注入。你能澄清一下吗？

Question

对 DI 越来越熟悉，但我仍然有一些小问题。

阅读一些文章，上面写着“必须在入口点进行注入”

假设我有一种情况，我们有 wcf 服务，这些服务供内部 win/web 应用程序使用，而外部第三方使用这些 wcf 服务。

现在您在哪里注入服务和存储库？ 以上对我来说似乎是一个常见的场景！

我还传递了所有这些接口。（非常适合模拟）我如何阻止某人从应该不调用存储库的层调用 EG 我的存储库。

EG 只有业务层应该调用 DAL。 现在，通过将 IRepository 注入控制器，开发人员可以调用 DAL。

有什么建议吗？清除所有这些的链接

我的可怜人 DI 的点头示例。我如何在 entryPoint 使用 unity 和 Injecting all 来做同样的事情？

[TestFixture]
public class Class1
{
    [Test]
    public void GetAll_when_called_is_invoked()
    {
        var mockRepository = new Mock<ICustomerRepository>();
        mockRepository.Setup(x => x.GetAll()).Verifiable();

        new CustomerService(mockRepository.Object);
        ICustomerBiz customerBiz = new CustomerBizImp(mockRepository.Object);

        customerBiz.GetAll();
        mockRepository.Verify(x=>x.GetAll(),Times.AtLeastOnce());
    }
}
public class CustomerService : ICustomerService  //For brevity (in real will be a wcf service)
{
    private readonly ICustomerRepository _customerRepository;

    public CustomerService(ICustomerRepository customerRepository)
    {
        _customerRepository = customerRepository;
    }

    public IEnumerable<Customer> GetAll()
    {
        return _customerRepository.GetAll();
    }
}

public class CustomerBizImp : ICustomerBiz
{
    private readonly ICustomerRepository _customerRepository;

    public CustomerBizImp(ICustomerRepository customerRepository)
    {
        _customerRepository = customerRepository;
    }

    public IEnumerable<Customer> GetAll()
    {
        return _customerRepository.GetAll();
    }
}

public class CustomerRepository : ICustomerRepository
{
    public IEnumerable<Customer> GetAll()
    {
        throw new NotImplementedException();
    }
}
public interface ICustomerRepository
{
    IEnumerable<Customer> GetAll();
}

public interface ICustomerService
{
    IEnumerable<Customer> GetAll();
}

public interface ICustomerBiz
{
    IEnumerable<Customer> GetAll();
}

public class Customer
{
    public int Id { get; set; }
    public string Name { get; set; }
}

谢谢

Answer 1

这是一篇关于Composition roots 的博文，或者您所说的入口点。它来自 Dependency Injection in .NET 的作者 Mark Seemann。如果您正在寻找对 DI 的深刻理解，这本书是必读的。

有很多关于如何结合 WCF 和 DI 的示例。如果你在 IIS 中托管你的服务，你需要编写一个自定义的 ServiceHostFactory 来初始化你的 DI 容器。这是Microsoft's Unity 的示例。

至于

如何阻止某人从不应调用存储库的层调用 EG 我的存储库

您是否使用穷人的 DI 并通过所有层传递所有引用？那么您绝对应该考虑使用 DI/IoC 容器，例如 StructureMap、Castle Windsor、AutoFac 或 Unity。

如果您问“我一般如何避免有人不遵循我的层边界的情况”：如果程序集引用另一个它不应引用的程序集（例如 UI 不应引用 DAL），则编写失败的测试。

---

更新

我假设您希望服务使用 ICustomerBiz 而不是 ICustomerRepository。如果这是正确的，Unity 的设置将如下所示：

[TestMethod]
public void GetAll_with_Unity()
{
  var container = new UnityContainer();
  container.RegisterType<ICustomerRepository, CustomerRepository>();
  container.RegisterType<ICustomerBiz, CustomerBizImp>();
  container.RegisterType<ICustomerService, CustomerService>();
  var svc = container.Resolve<ICustomerService>();
  var all = svc.GetAll();
  Assert.AreEqual(1, all.Count());
}

Answer 2

DI 更多的是在你的依赖架构中注入一个依赖，这就是为什么它不能解决你面临的层隔离问题。

如果需要，生产代码可以并且应该包含DI 代码。

• 如果我们谈论的是 plugin-based architectureDI 是最自然的选择之一。

• 如果我们谈论的是应用程序行为更改，例如Logging 系统选择：如果连接存在，则保存在远程服务器上，如果不注入本地记录器以供将来与服务器同步。

DI 在生产环境中有很多用法，但所有这一切都取决于Architect 来决定何时、如何和如果 em> 使用它。

换句话说，它没有单一的使用规则，它不是任何钉子的悍马，所以在你认为合适的地方使用它并明智地使用它。