Biztalk应用程序结构说明

我是新来的。我希望将我的工件组织成应用程序

---

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

这实际上是一个判断调用。如果你有一个包含很多模式、地图、编排的大型应用程序，当然，把它们分开是有意义的

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

对于一个新的BizTalk开发人员，我会坚持使用一个“MyBusinessProcess”应用程序。在某个时刻，当一个多项目解决方案开始有意义时，您将看到一个问题，然后执行它

我应该为每个工件类型使用一个应用程序吗

我想一般来说，你是说每种工件类型一个项目？尽管多个应用程序共有的工件应该被分割成一个单独的应用程序/解决方案

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

这些问题大部分都是在

需要详细说明的一点是，依赖关系链通常如下所示：

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

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

在部署了多个应用程序的服务器上，在某些情况下，您可能需要具有跨应用程序的依赖关系（特别是如果您选择耦合到确定的模式，而不是松散耦合，例如通过多部分消息），这通常是多个项目共有的依赖关系

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

以下是此场景的结构：

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

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

您的应用程序解决方案引用了上述内容，然后按照工件类型的不同进行了分析：

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

---

您所指的@StuartLC问题可能与“多个项目”有关，但我要问的是多个应用程序（biztalk类型）。请去掉重复的标签。我已撤回投票。BizTalk应用程序通常围绕功能而不是工件类型进行分组（即，标准通常是一个项目=一个程序集。解决方案中的多个项目=一个应用程序）。然而，应用程序实际上只是一个容器，除了逻辑分组之外几乎没有增加任何附加值。感谢你在这方面的发言，以及你的场景结构，我从中得到了很多。实际上，我的意思是“每种工件类型一个应用程序”，因为这就是我工作场所当前的结构。一个dll=一个biztalk应用程序。特别是，我正在接管这个安装，我正在考虑以不同的方式构建它，因为所有这些应用程序都把我搞糊涂了。所以我的问题更多的是一个“什么是最佳实践”的问题。你的回答对我帮助很大。