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

Question

我已经读过将BizTalk解决方案拆分成多个项目的好习惯，并且已经看到关于拆分的确切性质的一些争论，例如： ...
- 可以通过工件拆分，即Schemas，Orchestrations，Maps等。
- 可以按功能分开

但是有什么好处/骗局？

Answer 1

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

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

好处包括：

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

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

其他缺点包括：

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

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

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