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

本文关键字：一下 依赖 注入 何时何地 | 更新日期: 2023-09-27 18:19:09

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

阅读一些说"注入必须在入口点完成"的文章

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

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

我还传递了所有这些接口。(非常适合嘲笑)我如何阻止某人从应该而不是调用存储库的层调用EG我的存储库。

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

任何建议吗?清除所有这些的链接

我可怜的男人DI的例子。我如何使用unity并在entryPoint注入所有内容?

[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; }
}

谢谢

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

这是一篇关于组合根或者你称之为入口点的博文。它来自Mark Seemann， . net依赖注入的作者。如果你正在寻找对DI的深入理解，这本书是一本必读的书。

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

to

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

您是否使用了穷人的DI并在所有图层中传递所有引用?那么你绝对应该考虑使用DI/IoC容器，如StructureMap、Castle Windsor、AutoFac或Unity。

如果你在问"我如何才能避免有人不遵循我的层边界的情况":如果一个程序集引用了另一个它不应该引用的程序集(例如UI不应该引用DAL)，则编写失败的测试。

我假设您希望服务使用 iccustomerbiz 而不是 iccustomerrepository 。如果这是正确的，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());
}

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

如果需要，

生产代码可以和应该包含DI代码。

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

  • 如果我们谈论的是应用程序的行为改变，比如Logging系统选择:保存在远程服务器上，如果连接存在，如果没有注入本地记录器，以便将来与服务器同步。

DI在生产中有很多用法，但所有这些都取决于Architect来决定何时， 如何以及是否使用。

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

相关文章：