【问题标题】:How can I inject second databaseContext for API Configuration如何为 API 配置注入第二个 databaseContext
【发布时间】:2016-03-26 14:37:30
【问题描述】:

我正在构建一个 WebApi,但我有一些问题......

我为每个请求创建了服务,例如产品、客户、销售等。每个服务注入从基础存储库继承的存储库表,例如:

public ProductService(IProductRepository productRepository,
                      IProductPriceRepository productPriceRepository,
                      IProductProviderRepository productProviderRepository)
{
}

例如,SaleService 需要其他服务,例如:

public SalesService(IDocumentService documentService,
                    ICustomerService customerService,
                    IProductService productService)
{   
}

这或多或少是我的应用程序的架构。 问题是我需要另一个用于 API 配置的数据库上下文,如何在不使注入冗余的情况下实现这一点的正确方法是什么?喜欢:

public ProductService(IProductRepository productRepository,
                      IProductPriceRepository productPriceRepository,
                      IProductProviderRepository productProviderRepository,
                      ConfigurationApiContextService configurationApicontextService)
{
}
public SalesService(IDocumentService documentService,
                    ICustomerService customerService,
                    IProductService productService,
                    ConfigurationApiContextService configurationApicontextService)
{           
}

我正在使用 IoC Unity。 这是向服务添加另一个 dataContext 的正确方法吗?是否可以让整个应用都可以全局访问新的 dataContext?

如果这是正确的方法,如果以后我想添加 log4net 包来记录整个应用程序,是否有太多的服务注入?

抱歉这些问题,刚开始使用 WebApi ;)

对于英语不好也很抱歉。

提前致谢。

【问题讨论】:

  • 您会在当前存储库中使用第二个数据库上下文吗?或者只是 ConfigurationApiContextService 将使用第二个数据库上下文?
  • 只是配置apicontext 将使用ti第二个数据库上下文,它只是客户端发送的数据和最终存储在系统上的数据之间的数据解析器。问题是,当例如 salesservice 依赖于 poductservice 时,是否有一些方法可以不重复注入。感谢您的遮阳篷 :)

标签: c# dependency-injection asp.net-web-api2


【解决方案1】:

你的构造函数不应该有很多参数。但是你有 4 个参数,所以没关系。您可以使用Aggregate Services 组合服务(如果它们具有逻辑或心理关系,则组合)。

例如,如果您的 customerService 和 Document 服务始终在一起,请为它们创建一个聚合服务。如果您阅读Refactoring to Aggregate Services 文档,您会了解更多。

但据我所知,您已经在产品服务上这样做了。

我建议你使用ConfigurationApiContextService的接口。这样您就可以轻松地进行测试,并摆脱与实现的耦合。

您不能与规则(接口)松散耦合,但您可以与依赖注入中的实现松散耦合。此外,您决定在顶层而不是在中间或底层实现(控制反转)。

因此,您的销售服务与产品服务规则 (IProductService) 相结合,而不是与实施相结合。

【讨论】:

    猜你喜欢
    • 2021-05-10
    • 2013-05-31
    • 1970-01-01
    • 2012-08-26
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2016-05-26
    • 1970-01-01
    相关资源
    最近更新 更多