在我的测试项目中，我创建了一个 WCF 服务并让它运行。接下来，我创建了一个 MVC 4 项目。它在一种解决方案下被分成几层。
做一个快速测试：在 UI 层，我添加了一个对我的 WCF 服务的 Web 引用。在控制器中，我通过“使用”在视图中填充下拉列表来联系 WCF 服务。
但是，我正在使用依赖注入进行分离。
在存储库层中，我创建了一个带有填充下拉列表的接口并将其注入。不是问题。
我在这个概念上苦苦挣扎的是：
这给我带来了另一个问题 - 如果我在单独的项目（层）中创建对 WCF 服务的 Web 引用，则与 WCF 服务有关的信息不会出现在主 config.sys 文件中......
所以我正在努力掌握这部分......我应该阅读更多内容吗？
意识到你的蛋糕可以用多种方式切割，我在这里向你介绍我对如何切割它的看法：
问题 #1：“我是否在 UI 层使用 WCF 服务并在存储库层引用它？” 首先：正如 Steven 在您的评论中指出的那样，您应该深入考虑是否要注入第三个服务器层。UI 层可以重命名为“在 IIS 中托管的层”。这样做使它成为 MVC 表示层和服务的主机层的主机层。但是，这并不意味着您的服务是在这一层实现的，只是它们托管在这里（仅在 web.config 中引用接口和实现命名空间的问题）。
问题 #2：“我是否创建另一个项目 - 数据层 - 并添加对 WCF 服务的 Web 引用，然后从存储库中创建对数据层的引用？” 当我读到这篇文章时，您同时提出了多个问题：是的，您应该创建一个单独的层来封装存储库。不，您不应该让该层包含与 wcf 相关的任何内容。如果服务器层需要客户端访问 wcf 服务，您应该将其分成一个逻辑层，或者作为一个文件夹驻留在您的业务逻辑层中，或者作为一个单独的物理“数据适配器层”。永远不会在您的存储库层中。虽然从概念上讲 wcf 数据适配器层与存储库层处于同一级别，但您不应该在同一逻辑或物理层中混合使用数据库访问和服务访问。
第三个问题我只能作为一个问题来回答：您希望 WCF 在您的体系结构中实现的目的是什么？您是要注入单独的服务层还是将层分离与层分离混淆了？
层分离可以在进程内耦合运行时，而层分离只能通过某种在线远程处理（例如 wcf）耦合运行时。
正如 Steven 在他的评论中指出的那样，您根本没有真正记录在您的架构中使用 wcf 的必要性。
让我们从逻辑层和层次的角度来看看你的架构（切蛋糕）：
客户端访问层（#1，在浏览器上下文中运行）
Web-Host-Layer（#2，代表外部服务器层，包含所有 MVC 代码。也许 Model 存在于它自己的物理层中。
服务层（在您的架构中尚不存在，因为没有必要证明将层进一步抽象为层）
业务层（#2，表示位于表示层和数据库以及数据访问层之间的业务逻辑）
存储层（#2，封装数据库访问逻辑和映射）
服务访问层（#2，封装对外部服务的访问，可以实现为BL层的文件夹，也可以单独的物理层实现）
数据库层（#3，sql server）
那么您是否在问如何使用 IIS 作为主机和 C# 作为实现语言在 WCF 中实现 DI。
或者。
您是否在询问构建 n 层 .net 应用程序的一般指导。
第一个很简单，因为那里有很多例子，比如这个
第二个更棘手，因为答案总是“取决于”。这取决于您的需求是什么，您的专业水平是什么，项目的预计时间跨度是多少等等。
希望这对您有所帮助。
如果您愿意，我可以将我的行为 wcf unity 的实现发送给您。
概念：
逻辑层 - 用于隔离责任的架构概念。层具有向下耦合，从不向上。
物理层 - 用于实施逻辑分离的实现结构。.net 程序集可用作物理层的实现。
层 - 可以存在于不托管其他层的机器上的一个或多个层。
在我看来，您将 WCF 调用视为数据源，这使其自然适合存储库层。存储库的工作是从其他层抽象数据源实现的知识。
我建议不要使用 .NET 项目来强制执行层边界，而是使用同一项目中的文件夹来强制执行逻辑分离而不是物理分离。大多数用例不需要物理分离，它会增加复杂性，例如您提到的更困难的配置。