共享包含WCF接口和数据合同的项目，并使用ChannelFactory来消费服务，符合SOA原则吗？
我的架构师建议使用Add Service Reference生成代理更可取。
4个回答
0
我猜这取决于一些因素：您的基础设施、安全策略、治理等。
我们设计我们的WSDL（服务和消息契约）和XML模式（数据契约），然后使用svcutil.exe*生成代理。此时，我们有了可以用来消耗或建立服务的代码。当然，我只是在谈论代码，输出.config将根据决定进行适当的行为、绑定和端点修改。
一旦服务启动，它就会被一个XML网关所覆盖。此时，我们可以使用“添加服务引用…”来开始测试服务。如果你只是想节省一些时间并将预先生成的代理或你的WSDL不暴露出来（因为它们在不回显它们的XML网关后面），那么你正在做的事情似乎很好。
否则，我希望消费者能够“添加服务引用…”并生成自己的客户端。
*基于Java的应用程序使用其他工具（WSDL2Java/ClientGen/内置IDE工具）。
- Jason Alati
0
在SOA原则下，共享预打包的服务接口和数据契约并不违反原则，只要消费服务不需要使用它。这正是使潜在客户能够加速开发现有第三方服务或开始开发尚未构建的服务的关键所在。提供代码格式的接口/数据契约将比仅通过文档描述这些内容更少歧义（当然，如果客户端使用不同的编程语言，则可能无用）。
然而，如果在共享包中提供了某种预打包的服务接口实现，并且需要使用此实现才能成功使用服务，则除非为所有类型的客户端编写了实现，否则这将违反SOA原则。虽然务实起见，这可能是个好主意，这样客户端就可以更松散地耦合传输选择、服务契约变更和服务版本控制等问题。
我建议使用ChannelFactory（当然是从dotnet客户端）来消费服务，无论是通过共享的预打包接口/数据契约项目或dll，还是生成自己的代理（通过“添加服务引用”或“svcutil.exe”）。这将允许您针对服务接口进行编码，因此您的客户端将更友好地使用诸如依赖注入之类的概念进行存根、测试等操作。
- Bermo
0
我们公司认真考虑并采用的标准是，我们以两种方式分发服务合同。当交付给公司内部团队时，作为共享程序集；当提供给客户和其他第三方时，则作为 WSDL 文件。这是我们在设计/流程审查期间与 Microsoft 讨论过的标准，他们同意这是正确的方法。
- Kristen
0
生成代理的两种方法都是有效的，这取决于您希望对代理拥有多少控制权，以及是否同时拥有代码的双方。还存在第三个选项，您可以手工制作自己的代理。让我进一步解释：
在面向服务架构（SOA）中，我们传递消息，这与在面向对象（OO）世界中传递指向堆/栈上对象的指针是不同的范式。
因此，在SOA中，契约（您可以做什么）和消息（要执行操作的状态）非常重要，并且需要与服务的消费者共享，以便他们可以就契约或“参与规则”达成一致。这是SOA的最基本形式。
然后进入WS-*，它是一套用于为我们的服务调用添加更多功能的规范（分布式事务，安全性等）。但是，如果我们这样做，我们所有人都需要就规则和所使用的交互类型的风格达成一致，因此服务及其客户端需要完全一致地协商如何进行这种交互，因此需要进行共享。
契约定义和WS-*规范的组合被称为WSDL，通常这是客户端和服务之间共享的内容，这符合SOA的原则，即我们共享模式和契约，而不是类，并且兼容性基于策略（WS-*）。
如果您使用通道工厂，您将根据您拥有的接口定义和在运行时设置的配置生成代理。如果您使用添加服务引用，则让IDE基于服务的WSDL生成代理类。
如果您手工制作代理，您可以完全控制它的生成方式，并且可以进入拦截链并在客户端上执行操作以操纵调用。
这取决于您想要做什么。
- MetalLemon
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接