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

Question

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

但是有什么好处/缺点？

Answer 1

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

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

好处包括:

基于关注点的分离
工件的逻辑分组(通过
功能或工件类型
例子)。这种方法减少了
修改方面的可能性
您的解决方案与
你正在处理的问题
时间。

更容易测试——你可以编译和
只部署你的组件
修改。

更容易在一组人之间分配工作
开发商。

当解决方案更易于管理
变大——可能需要几个
加载大型 BizTalk 的分钟数
Visual Studio 中的解决方案。

支持更高级的方法
与 ESB 风格的解决方案相关(非常
松耦合)。取决于你的
总体方法，您可以创建一个
非常模块化的解决方案——
模块可以操作的点
并完全更新
彼此独立。

使版本成为可能
工件分开。

促进更细粒度的控制
过度安全和内存利用率
通过对相关功能进行分组，例如
您将它们部署到特定的
主机实例，例如(您可以
还管理细粒度的 .NET
安全策略比
您可以使用部署的解决方案
几个程序集)。

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

其他缺点包括:

更多要签名和部署的程序集
进入广汽

之间的相互依赖
项目可能会导致部署
可能难以解决的错误
在组织不善的情况下追踪
解决方案。

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

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