当您的服务引用被抽象到 API 之后时管理 WCF 配置
我有一些通过 WCF 服务公开的域逻辑。我没有在我的 MVC Web 应用程序中显式编写 WCF 代理调用等，而是将 WCF 服务引用包装到它们自己的项目中 - MyProject.BizLogic.Endpoint - 然后将此项目的引用添加到我的 Web 应用程序中。
这对于保持控制器代码的整洁和可读性非常有用 - Endpoint 公开了一个 ICrmSystem 接口，其中包含 RetrieveCustomerDetails(int customerId) 等很好的抽象方法，然后在包装到 CustomerQuery DTO 中的端点类中并在远程 CustomerQueryHandler 服务上触发。对于隔离测试，您只需模拟 ICrmSystem 并根据模拟的实现测试控制器方法。
事实是 - WCF 需要大量神秘而微妙的配置，目前我必须在我的 Web 应用程序的 web.config 文件中拥有整个 system.serviceModel 绑定和客户端配置。
是否有更简洁的方法来管理此配置 - 最好作为端点抽象模块的一部分，这样 Web 开发人员甚至不需要知道 WCF 在幕后进行？我可以以某种方式将对端点配置文件的引用放入我的网络应用程序中吗？或者以编程方式而不是声明方式管理 WCF 配置？
谢谢，
迪伦
I have some domain logic exposed via WCF services. Rather than explicitly writing WCF proxy calls, etc. in my MVC web application, I've wrapped the WCF service references up into their own project - MyProject.BizLogic.Endpoint - and then added a reference to this project to my web app.
This is great for keeping the controller code clean and readable - Endpoint exposes an ICrmSystem interface with nicely abstracted methods like RetrieveCustomerDetails(int customerId), and then within the endpoint class that's wrapped up into a CustomerQuery DTO and fired off at a remote CustomerQueryHandler service. For isolation testing, you just mock ICrmSystem and test the controller methods against the mocked implementation.
Thing is - WCF needs lots of cryptic and delicate configuration, and at the moment I have to have the whole system.serviceModel bindings and client configurations in my web app's web.config file.
Is there a cleaner way of managing this configuration - preferably as part of the Endpoint abstraction module so the web developers don't even need to know that WCF is going on behind the scenes? Can I put a reference to the Endpoint's config file into my web app somehow? Or manage WCF configuration programatically instead of declaratively?
Thanks,
Dylan
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
事实证明，您可以将配置部分隔离到一个单独的文件中，这在保持配置隔离和仍然允许在运行时进行编辑之间提供了很好的平衡。
我的 Web.config 现在包含：
这意味着实际的端点端口/协议/等。可以隔离在自己的子文件夹中。该文件夹现在被配置为我们的 VCS 中的外部（子模块），因此，如果我们更改某个基础设施（例如，将服务移动到不同的物理服务器上），我们可以更新配置、提交这些更改、更新任何项目对这些配置部分的依赖，并避免在多个部署的应用程序中手动更新配置文件。
唯一需要注意的是，IIS 不会像检测主 Web.config 那样检测到这些文件的更改，因此修改文件后，您需要触摸 web.config 或重新启动 Web 应用程序。除此之外，它的效果非常好。
It turns out you can isolate configuration sections into a separate file, which offers a nice balance between keeping the config isolated, and still allowing editing at runtime.
My Web.config now contains:
which means the actual endpoint ports/protocols/etc. can be isolated in their own subfolder. This folder is now configured as an external (submodule) in our VCS, so that if we change a piece of infrastructure - say, move a service onto a different physical server - we can update the configuration, commit those changes, update any project with a dependency on those configuration sections, and avoid having to manually update config files in multiple deployed apps.
Only caveat is that IIS won't detect changes to these files as it does with the main Web.config, so after modifying one you'll either need to touch web.config or restart the Web app. Other than that, it works quite nicely.
将其保留在配置中。由于能够立即将服务指向其他地方或动态添加新行为，我已经被拯救了太多次，次数太多了。编码 = 编译 = 更难更改
Keep it in the config. I've been saved too many times by being able to instantly point services elsewhere or add new behaviors on the fly too many times to count. Coded = Compiled = Harder to Change