将第 3 方接口（通过 WCF）公开给 Silverlight
我搜索了很多，如果我错过了一些明显的东西，我很抱歉。感谢您阅读下面的长文。
我这里有一个第三方（阅读：无法访问/更改源）应用程序。它由服务器（Windows 服务）和 API 组成，API 通过远程处理与服务器通信。 出于多种原因，我想通过 WCF 公开此 API（请参阅主题：其中一个原因是 WCF 客户端）。
问题是，API 是
- 不可更改的（遵循第 3 方规则）
- ，不使用 WCF 本身（远程处理需要时可序列化/MarshalByRef），
- 使用大量接口和内部实现类
以下 1 我无法使用（相当侵扰）WCF 属性是我自己的。
遵循 2，API 本身可以“通过网络”使用（它们支持通过 TCP 和 HTTP 进行远程处理），但远程处理对我来说还不够好。
在 3 之后，我主要有接口（WCF 不能很好地处理这些接口，不能（反）序列化）。实现类可以发送过来，但是 - 我无法访问它们。
该 API 的一般用法是基于单个接口（及其成员/属性），因此典型用法如下
var entryPoint = new ApiClientEntryPoint();
entryPoint.SomeMethodCall();
entryPoint.PropertyExposingAnInterface.SomeOtherMethodCall();
。
我真正想做的是（用尽可能少的努力/代码）生成一个代理（不是典型的 WCF 意义上的代理），我通过 WCF 公开该代理，并将该层次结构序列化，将客户端上的每个调用/属性映射到服务器上真实的东西。
到目前为止，我最接近的是偶然发现这个项目，但我想知道是否还有更多/其他可用的工具可以帮助我承担这项工作的中到大部分工作。
如果有任何一般性的其他建议、更好的方法将预先存在的且不可更改的内容包装到 WCF 中，请分享。
I searched a lot, apologies if I missed something obvious. And thanks for reading the looong text below.
I have a 3rd party (read: No way to access/change the source) application here. It consists of a server (Windows service) and an API, that talks to the server via remoting.
For several reasons I'd like to expose this API over WCF (see subject: One reason is a WCF client).
The problem is, the API is
- unchangeable (follows 3rd party rule)
- using no WCF itself (it is serializable/MarshalByRef where necessary for Remoting)
- using lots of interfaces and internal implementation classes
Following 1 I cannot use the (quite intrusive) WCF attributes myself.
Following 2 the API itself can be used "over the wire" (they support remoting via TCP and HTTP), but remoting is not good enough for me.
Following 3 I have mostly interfaces (which WCF won't handle well, cannot (de-)serialize). The implementation classes could be sent over, but - I cannot access them.
The general usage for this API is based on a single interface (and its members/properties), so the typical usage is like
var entryPoint = new ApiClientEntryPoint();
entryPoint.SomeMethodCall();
entryPoint.PropertyExposingAnInterface.SomeOtherMethodCall();
and so on.
What I'd really like to do is generate (with as little effort/code as possible) a proxy (not in the typical WCF sense) that I expose via WCF and that serializes this hierarchy mapping every call/property on the client to the real thing on the server.
The closest I've come so far is stumbling upon this project, but I wonder if there are more/other tools available that take a medium to large part of this work off my shoulder.
If there are any general other advices, better approaches to wrap something preexisting and unchangable into WCF, please share.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我的建议是使用外观模式。创建特定于您的使用情况的新 WCF 服务并包装第 3 方服务。客户会与您的服务交谈，而您会与第三方交谈。但客户不会直接与第三方交谈。
这适用于大多数情况，但并非所有情况。我不确定你的具体情况，所以 YMMV。
顺便说一句，您可以查看 WCF RIA Services，它非常适合将服务公开给 Silverlight，这样您就可以避免对服务内容进行大量手工编码。但同样取决于您的具体情况，这可能不是最好的方法。
编辑：
现在很明显，为了有效地使用外观，API 太大和/或客户端的使用模式太多样化。我唯一可以建议的就是考虑使用代码生成工具。使用反射（假设它是 .NET API？）来分解 API，然后使用您收集的详细信息生成新服务。您可以查看 Visual Studio 中内置的 T4 模板，也可以查看更“强大”的工具，例如 CodeSmith。但我猜这会是一些写起来很痛苦的代码。我不知道有什么自动化的解决方案。
API 是否有详细记录？如果是，文档是否采用可解析的格式，例如 XML 或结构良好的 HTML？在这种情况下，您可能可以从文档中进行代码生成，而不是通过代码反映。根据具体情况，这可能会更快。
My advice is to use a facade pattern. Create a new WCF service that is specific to your usage and wrap the 3rd party service. Clients would talk to your service and you would talk to the 3rd party. But clients would not talk to the 3rd party directly.
This would work in most but not all scenarios. I'm not sure of your particular scenario so YMMV.
BTW you can look at WCF RIA Services which is good for exposing services to Silverlight where you can avoid doing a lot of the hand coding of service stuff. But again depending on your particular scenario it might not be the best way to go.
Edit:
It's now clear that the API is too big and/or the usage patterns of the clients are too varied in order to effectively use a facade. The only other thing I can suggest is to look at using a code generation tool. Use reflection (assuming it is a .NET API?) to pull apart the API and then codegen new services using the details you gathered. You could look at the T4 templates built into Visual Studio or you could look at a more "robust" tool such as CodeSmith. But I'm guessing this would be some painful code to write. I'm not aware of an automated solution for this.
Is the API well documented? If so, is the documentation in a parseable format such as XML or well-structured HTML? In that case you might be able to codegen from the documentation as opposed to reflecting through the code. This might be quicker depending on the particulars.
好吧，我这边的方案#1 很费脑子：
您唯一的其他选择是使用 T4 code gen ，这可能比上述想法花费更长的时间。
Okay, hair brained scheme #1 on my side:
Your only other option will be to use T4 code gen ,which will probably take longer than the above idea.