Biztalk 应用程序结构操作指南答案

【问题标题】：Biztalk Applications structure how-toBiztalk 应用程序结构操作指南
【发布时间】：2014-02-14 14:16:25
【问题描述】：

我是 Biztalk 的新手。我希望将我的工件构建到应用程序中。

我是否应该为每种工件类型使用一个应用程序 - 例如 3 个单独的应用程序，例如“BusinessProcess.Schemas”、“BusinessProcess.Maps”、“BusinessProcess.Maps”，以及与这些相关的所有程序集（通常只有一个），还是您认为最好只有一个“BusinessProcess”应用程序，其中包含与业务流程相关的所有程序集？

【问题讨论】：

Why split a BizTalk solution into multiple projects 的可能重复项
@StuartLC 您所指的那个问题涉及“多个项目”，但我要求的是多个应用程序（biztalk 类型）。请删除重复的标签。
我撤回了我的投票。 BizTalk 应用程序通常围绕功能而不是工件类型进行分组（即，标准通常是一个项目 = 一个程序集。解决方案中的许多项目 = 一个应用程序）。然而，应用程序实际上只是一个容器，除了逻辑分组之外，几乎没有增加任何附加值。

标签： biztalk

【解决方案1】：

我是否应该为每种工件类型使用一个应用程序

我认为一般来说，您的意思是每种工件类型一个项目？尽管应将多个应用程序共有的工件拆分为单独的应用程序/解决方案。

将 BizTalk 项目拆分为组件项目（和程序集）的基本原理类似于任何其他 .Net 项目 - 关注点分离、用于测试目的的隔离、独立版本控制等。

其中大部分在Erik Westermann's great answer here 中得到解决

需要说明的一点是，依赖链通常看起来像这样：

Schemas (Internal / Canonical, External)
^
Maps
^
Ports + Pipelines
^
Orchestrations

（加上其他带有助手的杂项 .Net 程序集）

在部署了多个应用程序的服务器上，有时您可能需要跨应用程序依赖项（特别是如果您选择耦合到明确的模式而不是松散耦合，例如通过多部分消息），通常在 @987654322 @ 对多个项目来说是通用的。

除非这些架构与其他程序集分开，否则每当单体应用程序发生更改时，每次对单体应用程序进行任何更改时，您都需要经历卸载/重新安装所有相关应用程序的痛苦。一般来说，因为整个企业都依赖于规范模式，它们经过仔细考虑，因此相当稳定，而应用程序的地图和编排更可能是频繁更改的候选者。

下面是这个场景的结构：

单独的通用/基础解决方案项目：

通用内部架构（事件/EDA 元信息，内部错误等）
规范域模式（即内部/企业您的业务的发票、索赔、交易等模型）
用于与上述交互的辅助程序集

您的应用程序解决方案引用了上述内容，然后commonly accepted separation 符合工件类型：

外部系统架构（如果不止一个，则每个都在自己的程序集中）
地图
管道
编排

【讨论】：

感谢您的发言，以及您的场景结构，我从中得到了很多。我确实是指“每种工件类型一个应用程序”，因为这就是我工作场所目前的结构方式。一个 dll = 一个 biztalk 应用程序。特别地，我正在接管这个安装，我正在考虑以不同的方式构建它，因为所有这些应用程序都让我感到困惑。所以我的问题更像是一个“什么是最佳实践”的问题。你的回答对我帮助很大。

【解决方案2】：

这真的是一个判断电话。如果您有包含大量架构、地图、编排的大型应用程序，当然，将它们分开是有意义的。

但是，小型应用程序，10 个左右的工件，并没有那么多。

对于新的 BizTalk 开发人员，我会坚持使用“MyBusinessProcess”应用程序。在某个时候，您会看到多项目解决方案开始变得有意义，然后去做。

【讨论】：