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

Question

我已经读过将BizTalk解决方案拆分成多个项目的好习惯,并且已经看到关于拆分的确切性质的一些争论,例如......
- 可以通过工件拆分,即架构,编排,地图等.
- 可以按功能拆分

但是有什么好处/骗局？

Answer 1

BizTalk解决方案通常包括模式,映射和编排.解决方案还可以包括支持组件,业务规则,基于端口的路由和转换的定义,贸易合作伙伴以及其他几种类型的工件.

有效地管理所有这些工件有许多好处 - 远远超过缺点.

好处包括:

• 基于工件的逻辑分组(例如,按功能或工件类型)分离关注点.这种方法降低了修改解决方案的可能性,这些方面与您当时正在处理的问题无关.
• 更容易测试 - 您可以只编译和部署您正在修改的组件.
• 更容易在一组开发人员之间分配工作.
• 当解决方案变得更大时更容易管理 - 在Visual Studio中加载大型BizTalk解决方案可能需要几分钟.
• 支持与ESB风格解决方案相关的更高级方法(非常松散的耦合).根据您的整体方法,您可以创建一个非常模块化的解决方案 - 使模块可以完全独立地运行和更新.
• 可以单独编辑工件.
• 例如,通过对相关功能进行分组(例如,为特定主机实例部署它们)来促进对安全性和内存利用率的更细粒度控制(您还可以使用部署解决方案的解决方案更轻松地管理细粒度.NET安全策略)几个组装).

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

其他缺点包括:

• 要签署和部署到GAC的更多程序集
• 项目之间的相互依赖性可能导致部署错误,这些错误很难在组织不良的解决方案中进行跟踪.

您应该在项目开始时花一些时间 - 最好是在设计期间 - 来设置解决方案的基本组织.不存在一种通用的方法 - 您需要考虑在解决方案为您的组织或客户提供的功能的上下文中,在开发,部署和维护期间如何管理解决方案.

一个好的起点是根据工件类型或功能区域划分解决方案.随着您的解决方案的发展,您将更好地了解工件如何相互关联,如何管理强大的命名,安全性和物理部署,以及更有效地安排解决方案.您需要小心这种方法,因为最终可能需要重新安排解决方案的大部分内容,如果您的项目时间紧迫,这可能会造成破坏.