Asp.net mvc 当服务引用抽象到API之后时管理WCF配置
我通过WCF服务公开了一些域逻辑。我没有在我的MVC web应用程序中显式地编写WCF代理调用等,而是将WCF服务引用打包到它们自己的项目MyProject.BizLogic.Endpoint中,然后将对该项目的引用添加到我的web应用程序中 这对于保持控制器代码的干净性和可读性非常有用-Endpoint使用诸如RetrieveCustomerDetails(int customerId)之类的非常抽象的方法公开ICrmSystem接口,然后在Endpoint类中公开,该类封装到CustomerQuery DTO中,并在远程CustomerQueryHandler服务中启动。对于隔离测试,您只需模拟ICrmSystem并针对模拟的实现测试控制器方法 事实是——WCF需要很多神秘而微妙的配置,目前我必须在我的web应用程序的web.config文件中包含整个system.serviceModel绑定和客户端配置 是否有一种更干净的方法来管理这种配置——最好是作为端点抽象模块的一部分,这样web开发人员甚至不需要知道WCF正在幕后进行?我可以在我的web应用程序中添加对端点配置文件的引用吗?或者以编程方式而不是声明方式管理WCF配置 谢谢Asp.net mvc 当服务引用抽象到API之后时管理WCF配置,asp.net-mvc,wcf,configuration,wcf-endpoint,Asp.net Mvc,Wcf,Configuration,Wcf Endpoint,我通过WCF服务公开了一些域逻辑。我没有在我的MVC web应用程序中显式地编写WCF代理调用等,而是将WCF服务引用打包到它们自己的项目MyProject.BizLogic.Endpoint中,然后将对该项目的引用添加到我的web应用程序中 这对于保持控制器代码的干净性和可读性非常有用-Endpoint使用诸如RetrieveCustomerDetails(int customerId)之类的非常抽象的方法公开ICrmSystem接口,然后在Endpoint类中公开,该类封装到Customer
迪伦将其保存在配置中。我已经节省了太多的时间,因为我能够立即将服务指向其他地方,或者在运行中添加太多的新行为。Coded=Compiled=Harder to Change事实证明,您可以将配置部分隔离到一个单独的文件中,这在保持配置隔离和仍然允许在运行时编辑之间提供了一个很好的平衡 My Web.config现在包含:
<system.serviceModel>
<bindings configSource="services/bindings.config" />
<client configSource="services/myservice.endpoint.config" />
</system.serviceModel>
这意味着实际的端点端口/协议/等可以隔离在它们自己的子文件夹中。现在,此文件夹在我们的VCS中配置为外部(子模块),因此,如果我们更改一个基础设施(例如,将服务移动到另一个物理服务器),我们可以更新配置、提交这些更改、更新依赖于这些配置节的任何项目,并避免在多个部署的应用程序中手动更新配置文件
唯一需要注意的是,IIS不会像对主Web.config那样检测到对这些文件的更改,因此在修改一个文件后,您需要触摸Web.config或重新启动Web应用程序。除此之外,它工作得很好