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