Biztalk 关于分离WCF生成项的架构和业务流程程序集的建议

使用consume WCF/generated items向导时，生成的项目包括模式、绑定以及包含用于使用服务的端口类型定义的ODX

将架构从业务流程分离到单独的程序集中是常见/良好的做法

然而，在WCF生成的工件的情况下，分离这些工件的努力是相当大的，因为必须编辑每个端口类型以指向引用程序集-对于具有许多操作（以及每个操作的请求/响应）的服务，这可能会很麻烦。如果WCF服务发生更改并需要重新生成，情况会变得更糟

因此，如果我可以问：

你认为这里最好的做法是什么？我倾向于在模式程序集中保留端口类型和虚拟ODX

是否将生成的端口类型移出生成的虚拟ODX，然后删除虚拟ODX

---

谢谢

我觉得你太努力了

我要做的是将所使用的WCF服务的服务引用放在自己的编排中（没有任何逻辑）。只是一个简单的业务流程，其中只定义了端口类型。然后，此业务流程可以位于单独的程序集中

这样，您就可以从其他项目中引用此编排

---

您不应该尝试将生成的架构与端口类型分开。无论如何，这些都是密不可分的，因为它们都是“服务合同”的一部分。

谢谢-你的建议被采纳了。让生成的代码保持独立/不受影响的做法会覆盖其他问题。为了提供上下文，需要在多个BizTalk应用程序中的多个业务流程之间共享通用WCF模式。事后看来，另一种方法是使用额外的规范模式进行触发，这样WCF生成的项就只需要“主”应用程序使用。要确认Maxine的模型工作良好，viz将生成的工件全部放在一个地方——带有生成的端口类型和多部分模式的令牌ODX——并放在一个单独的程序集中。这样，如果您的对等WCF服务接口发生更改，只需删除所有内容并重新创建生成的项。单独程序集的一个警告是，您需要手动将端口和架构的类型修饰符（范围可见性）从内部更改为公共，然后才能从业务流程程序集访问它们。