WCF ChannelFactory违背SOA原则？
是否共享包含 wcf 接口和数据契约的项目，并通过 ChannelFactory 使用这些来根据 SOA 原则使用服务？
我的架构师建议最好使用“添加服务引用”生成代理。
Is sharing a project containing the wcf interface and datacontracts and using these via ChannelFactory to consume the service against SOA principles?
My architect is advising that generating a proxy using Add Service Reference is preferable.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我想这取决于一些事情：您的基础设施、安全策略、治理等。
我们设计 WSDL（服务和消息契约）和 XML 架构（数据契约），然后使用 svcutil.exe* 生成代理。那时，我们就有了可以用来使用或建立服务的代码。当然，我只是谈论代码，output.config 将根据决定的适当行为、绑定和端点进行修改。
一旦服务启动，它的前端就会有一个 XML 网关。此时，我们可以使用“添加服务引用...”开始测试服务。如果您只是想节省一些时间并将您预先生成的代理交给其他人，或者您的 WSDL 不会公开（因为它们位于不回显它们的 XML 网关后面），那么您所做的似乎很好。
否则，我希望消费者能够“添加服务引用...”并生成自己的客户端。
*基于 Java 的应用程序使用其他东西（WSDL2Java/ClientGen/内置 IDE 工具）。
I guess that depends on a some things: your infrastructure, security policies, governance, etc.
We design our WSDLs (service and message contracts) and XML Schemas (data contracts) and then use svcutil.exe* to generate a proxy. At that point, we have code we can either use to consume or stand up a service. Of course, I am just talking about the code, the output.config will be modified with proper behaviors, bindings and endpoints as those are decided.
Once the service is stood up, it's fronted by an XML gateway. At which point we can begin testing the services using the 'Add Service Reference...'. If you're just looking to save some time and hand someone else your pre-generated proxy or your WSDLs aren't exposed (as they're behind an XML gateway that does not echo them), then what you're doing seems fine.
Otherwise, I'd expect consumers to be able to 'Add Service Reference...' and generate their own clients.
*Java-based applications use something else (WSDL2Java/ClientGen/built-in IDE tool).
只要消费服务不希望使用它，与数据契约一起共享预打包的服务接口并不违反 SOA 原则。这正是使潜在客户能够加速现有第三方服务的开发，或开始针对尚未构建的服务进行开发的原因。以代码格式提供接口/数据契约将比仅通过文档描述这些内容更明确（当然，如果客户端使用不同的编程语言，它们可能没有用）。
但是，如果共享包中提供了某种预先打包的服务接口实现，并且需要使用此实现才能成功使用该服务，那么这将违反 SOA 原则，除非为所有类型编写实现的客户。不过，从务实的角度来看，这可能是一个好主意，这样客户端就可以与传输选择、服务合同更改和服务版本控制等事物更松散地耦合。
我建议使用 ChannelFactory（当然来自 dotnet 客户端），无论是通过共享的预打包接口/数据合同项目或 dll 使用服务，还是生成您自己的代理（通过“添加服务引用”或“svcutil.exe”） 。这将允许您针对服务接口进行编码，因此您的客户端将更友好地使用依赖注入等概念来进行存根、测试等。
Sharing pre-packaged service interfaces along with datacontracts isn't against SOA principles as long as consuming services are not expected to use it. This is exactly what enables potential clients to speed-up development against an existing 3rd-party service, or begin development against one which is yet to be built. Providing interfaces/datacontracts in code format will be less ambiguous than describing these things via documentation only (of course they may not be useful if the client is using a different programming language).
However, if some sort of pre-packaged implementation of the service interface is provided in the shared package, and this implementation is required to be used to successfully use the service, then this would be against SOA principles unless an implementation was written for all types of clients. Being pragmatic though, this can be a good idea so the clients can be more loosely coupled against things such as transport choice, service contract changes and service versioning.
I would recommend using the ChannelFactory (from a dotnet client of course) whether consuming the services via a shared pre-packaged interfaces/datacontracts project or dll, or generating your own proxy (via 'Add Service Reference' or 'svcutil.exe'). This will allow you to code against the service interface and therefore your client will be much more friendly to using concepts such as dependency injection for stubbing, testing, etc.
生成代理的两种方法都是有效的，这取决于您希望对代理拥有多少控制权，以及您是否拥有双方的代码。还存在第三个选项，您可以手工制作自己的代理。让我进一步解释一下：
在 SOA 中，我们传递消息，这是与将指针传递到堆/堆栈上的对象的不同范例，这是 OO 世界中的规范。
因此，在 SOA 中，契约（您可以做什么）和消息（要采取行动的状态）很重要，需要与服务的使用者共享，以便他们都能就契约或“参与规则”达成一致。我们有最基本的 SOA 形式。
输入 WS-* 一组规范，用于向我们的服务调用添加更多功能（分布式事务、安全性等...），但如果我们这样做，我们都需要就规则和我们想要的交互类型的风格达成一致。使用，因此服务及其客户需要就如何发生达成一致，以便需要共享。
契约定义和 WS-* 规范的组合称为 WSDL，这通常是在客户端和服务之间共享的内容，这符合我们共享架构和契约而不是类的 SOA 租户，并且基于兼容性关于政策 (WS-*)。
因此，如果您使用通道工厂，您可以根据您拥有的接口定义和动态设置的配置来生成代理，如果您使用添加服务引用，您可以让 IDE 根据服务的 WSDL 生成一个代理类，如下所示那么它就存在了。
如果您手工制作代理，您可以完全控制这是如何发生的，并且您可以跳入拦截链并在客户端执行操作来操纵调用。
取决于你想做什么。
Both methods of generating a proxy are valid, it depends on how much control you wish to have over the proxy, and if you own both sides of the code. A third option also exists, you can hand craft your own proxy. Let me explain further:
In SOA we pass messages, this is a different paradigm to passing pointers to objects on a heap/stack which is the norm in OO world.
Thus in SOA, the contract (what you can do) and the message (the state to act upon) are important and need to be shared with the consumers of the service so they can all agree on the contract or "rules of engagement" here we have the most basic form of SOA.
Enter WS-* a set of specifications for adding more functionality to our service call (distributed transactions, security etc...) but if we do this we all need to agree on the rules and the flavor of the type of interaction we intend to use, so the service and its clients need to agree exactly on how this is to occur so it to needs to be shared.
The combination of the contract definitions and WS-* specifications is called a WSDL and this typically is what get shared between clients and services, this is in line with the SOA tenants that we share schema and contract, not class, and that Compatibility is based on policy (WS-*).
So if you use channel factory you generate the proxy based on the interface definition you have and the config you have set up on the fly, if you use add service reference you let the IDE generate a proxy class based on the WSDL of the service as it exists then.
If you hand craft the proxy, you have full control over how this happens and you can jump into the interception chain and do things on the client side to manipulate the call.
Depends on what you want to do.
我们公司仔细考虑并采用的标准是，我们以两种方式分发服务合同。当交付给公司内的团队时作为共享程序集，以及当提供给客户和其他第三方时作为 WSDL。这是我们在设计/流程审查期间与 Microsoft 讨论的标准，他们一致认为这是正确的方法。
The standards we have carefully considered and adopted at my company, are that we distribute service contracts is two ways. As a shared assembly when delivered to teams within the company, and as a WSDL when providing to clients and other third parties. It is a standard we discussed with Microsoft during a design / process review and they agreed was the correct approach.