代码之家  ›  专栏  ›  技术社区  ›  Benjamin Podszun

向Silverlight公开第三方接口(通过WCF)

  •  0
  • Benjamin Podszun  · 技术社区  · 15 年前

    我搜索了很多,如果我错过了一些明显的东西,我道歉。感谢您阅读下面的龙文。

    我在这里有一个第三方(阅读:无法访问/更改源代码)应用程序。它由一个服务器(Windows服务)和一个通过远程处理与服务器对话的API组成。 出于多种原因,我希望在WCF上公开此API(请参阅主题:一个原因是WCF客户机)。

    问题是,API

    1. 不可更改(遵循第三方规则)
    2. 不使用wcf本身(如果远程处理需要,它是可序列化的/marshalbyRef)
    3. 使用大量接口和 内部的 实现类

    在1之后,我不能自己使用(非常侵入性的)wcf属性。

    接下来的2,API本身可以“通过网络”使用(它们支持通过TCP和HTTP进行远程处理),但是远程处理对我来说还不够好。

    接下来的3个我主要有接口(WCF处理不好,无法(反)序列化)。可以发送实现类,但是-我不能访问它们。

    此API的一般用法是基于单个接口(及其成员/属性),因此典型用法如下

    var entryPoint = new ApiClientEntryPoint();
    entryPoint.SomeMethodCall();
    entryPoint.PropertyExposingAnInterface.SomeOtherMethodCall();
    

    等等。

    我真正想做的是生成一个代理(尽可能少的工作/代码),我通过WCF公开它,它序列化这个层次结构,将客户机上的每个调用/属性映射到服务器上的实际内容。

    我到目前为止最接近的是绊倒 this project 但是我想知道是否有更多的/其他的工具可以把这项工作的大部分从我肩上卸下来。

    如果有任何一般性的其他建议,更好的方法来包装一些预先存在和不可进入的WCF,请分享。

    2 回复  |  直到 15 年前
        1
  •  0
  •   RationalGeek    15 年前

    我的建议是使用立面样式。创建一个特定于您的使用情况的新WCF服务,并包装第三方服务。客户会与您的服务部门交谈,而您会与第三方交谈。但是客户会 直接与第三方交谈。

    这在大多数情况下都有效,但并非所有情况下都有效。我不确定你的具体情况,所以YMMV。

    顺便说一句,您可以看看wcf ria服务,它有利于将服务公开给Silverlight,这样您就可以避免对服务进行大量手工编码。但根据你的具体情况,这可能不是最好的方法。

    编辑:
    现在很明显,API太大和/或客户机的使用模式变化太大,无法有效地使用外观。我唯一能建议的是使用代码生成工具。使用反射(假设它是.NET API?)使用您收集的详细信息分离API,然后编码新服务。您可以查看构建在Visual Studio中的T4模板,也可以查看更“健壮”的工具,如codesmith。但我猜这将是一些令人痛苦的代码。我不知道这方面的自动化解决方案。

    API是否有良好的文档记录?如果是这样,文档是可解析的格式,如XML还是结构良好的HTML?在这种情况下,您可能能够从文档中生成代码,而不是通过代码进行反射。根据具体情况,这可能更快。

        2
  •  0
  •   Doobi    15 年前

    好吧,发脑计划在我这边:

    1. 使用Visual Studio重构菜单在“apiclientrypoint”上“提取接口”。
    2. 创建一个新的WCF服务,该服务实现上述接口,并获取vs来为您生成方法存根。
    3. '对于PropertyExposingInterface.SomeOtherMethodCall'您必须扁平化接口,因为没有“嵌套”服务操作的概念。

    您唯一的其他选择是使用t4 code gen,这可能比上面的想法需要更长的时间。

    推荐文章