应用程序和基础设施项目的紧密耦合答案

【问题标题】：Tight coupling of Application and Infrastructure projects应用程序和基础设施项目的紧密耦合
【发布时间】：2019-11-23 12:43:36
【问题描述】：

在我的基础结构层中，我为 Azure 搜索查询服务创建了一个项目，该服务实现了（我自己的）ISearchQueryService 接口。

项目中还有一个索引模型，它使用各种 Azure 搜索特定属性进行标记。

两者都依赖于 Azure 搜索 SDK。

在项目中，我还为 Azure 搜索配置添加了一个模型（从 appsettings.json 读取）并注入到服务构造函数中。这具有特定于 Azure 搜索的属性值，例如 Azure 服务密钥。

我的服务实现的 ISearchService 方法允许使用 Azure 搜索 SDK 中的类来搜索索引。后者采用参数，例如带有字段名/值的 ODATA 过滤器表达式和用于排序的字段名列表。

我从应用层的控制器服务调用 ISearchQueryService 方法。

我希望 ISearchQueryService 方法尽可能通用，这样我就可以将参数值传递给服务，例如：

var departurePointSearchQueryDto = new DeparturePointSearchQueryDto
{
                Filter = $"{nameof(IndexedDeparturePoint.TransitType)} eq 0",
                OrderByFieldNames = new List<string>() { $"{nameof(IndexedDeparturePoint.DeparturePointName)}" }
};

我使用“nameof”在编译时检查索引字段名称，但这意味着我的控制器服务现在直接引用 Azure 搜索查询项目。

我不确定这是否是一个问题，因为索引模型、配置模型和 ISearchQueryService 方法签名高度特定于 Azure 搜索。切换到另一个搜索提供程序意味着无论如何都需要重写它们——没有简单的方法可以将一个实现换成另一个。

问。在此基础上，紧耦合是否合理？如果不是，我应该考虑什么？

【问题讨论】：

提供者改变的可能性有多大？
很难说，但我们在整个业务中都使用了 Solr、Elasticsearch 和 Examine，所以这是可能的。
有可能，是的，但根据您的经验，供应商在部署后发生变化的可能性有多大？回答这个问题将决定是否将其作为一个问题。理想情况下，您希望尽可能保持代码解耦，但有时现实世界胜过建议的做法。
公平竞争 - 通常一旦部署它们就不会改变。
所以我想这回答了你的问题。

标签： c# architecture

【解决方案1】：

感谢 @Nkosi 建议“理想情况下，您希望尽可能地保持代码解耦，但有时现实世界胜过建议的做法” - 请参阅 cmets。

但是，为了解决问题中描述的紧密耦合，我在我的域层中创建了一个 IIndexedDeparturePoint。 IndexedDeparturePoint 实现了 IIndexedDeparturePoint，我可以在 nameof 运算符中引用 IIndexedDeparturePoint。

我还移动了域层中的配置类，因此我已经尽可能地移除了耦合。

【讨论】：