为什么将 BizTalk 解决方案拆分为多个项目

Question

我已经阅读了将 BizTalk 解决方案拆分为多个项目的良好做法，并且看到了关于拆分的确切性质的一些争论，例如...
- 可以按工件分割，即模式、编排、地图等。
- 可以按功能拆分

但是有什么好处/坏处？？

Answer 1

BizTalk 解决方案通常包括架构、映射和业务流程。解决方案还可以包括支持组件、业务规则、基于端口的路由和转换的定义、贸易伙伴以及其他几种类型的工件。

有效地管理所有这些工件有很多好处——好处远多于缺点。

好处包括：

• 基于 工件的逻辑分组（通过 功能或工件类型 例子）。这种方法减少了 修改方面的可能性 您的解决方案与 你正在处理的问题 时间。
• 更容易测试 - 您可以编译和 只部署你的组件 修改。
• 更容易在一组人之间分配工作 开发人员。
• 当解决方案更易于管理 变大——可能需要几个 加载大型 BizTalk 的分钟数 Visual Studio 中的解决方案。
• 支持更高级的方法 与 ESB 风格的解决方案相关（非常 松耦合）。取决于你的 总体方法，您可以创建一个 非常模块化的解决方案—— 模块可以操作的点 并完全更新 彼此独立。
• 使版本成为可能 工件分开。
• 促进更细粒度的控制 过度安全和内存利用率 通过对相关功能进行分组，例如 您将它们部署到特定的 主机实例，例如（您可以 还管理细粒度的 .NET 安全策略比 您可以使用部署的解决方案 几个程序集）。

在调试解决方案时，将解决方案拆分到多个项目或解决方案表面的主要缺点。对于许多不熟悉 BizTalk 的开发人员来说，调试 BizTalk 解决方案并不简单，而且必须缩小解决方案中的错误范围并不会使工作变得更容易。但是，您可以通过更有效地安排您的解决方案并使用有关命名、目录结构、命名空间安排和相关方法的标准来管理这个问题，以便更容易找出在哪里查找。

其他缺点包括：

• 更多要签名和部署的程序集 进入 GAC
• 之间的相互依赖关系 项目可能会导致部署 可能难以解决的错误 在组织不善的情况下追踪 解决方案。

您应该在项目开始时（最好是在设计期间）花一些时间来设置解决方案的基本组织。不存在一刀切的方法——您需要考虑在解决方案为您的组织或客户提供的功能的背景下，在开发、部署和维护期间如何管理解决方案。

一个好的起点是根据工件类型或功能区域划分您的解决方案。随着您解决方案的发展，您将更好地了解工件之间的关系，您希望如何管理强命名、安全性和物理部署，并能够更好地更有效地安排您的解决方案。您需要谨慎使用这种方法，因为您最终可能不得不重新安排解决方案的大部分内容，如果您的项目时间紧迫，这可能会造成破坏。