BizTalkソリューションを複数のプロジェクトに分割する理由

Question

BizTalkソリューションを複数のプロジェクトに分割することをお勧めしましたが、分割の正確な性質についていくつかの議論がありました。 ...
- アーティファクトによって分割することができ、すなわちスキーマ、オーケストレーション、地図など
は - 機能

によって分割することができた。しかしメリット/ CONのは何ですか？

Answer 1

BizTalkソリューションには、通常、スキーマ、マップ、およびオーケストレーションが含まれています。ソリューションには、サポートコンポーネント、ビジネスルール、ポートベースのルーティングとトランスフォーメーションの定義、取引先、その他いくつかのタイプの成果物も含まれます。

これらの成果物のすべてを効果的に管理することには、多くの利点があります。

利点は、以下が挙げられる：（ 例えば 機能やアーティファクトタイプによる）アーチファクトの 論理グループに基づいて、関心の

• 分離。この方法では、 の解決策の可能性が、 時に解決している問題に関連しない解決策になります。
• テストするのが簡単です - コンパイルすることができ、 のコンポーネントをデプロイするだけで が変更されます。
• のグループの開発者の間で作業を分割しやすい。
• ソリューションが になったときの管理が簡単 - Visual Studioで大規模なBizTalk ソリューションをロードするには、数分かかることがあります（ ）。
• ESBスタイルのソリューションに関するより高度なアプローチ をサポートしています（非常に ルーズカップリング）。 の全体的なアプローチに応じて、 という非常にモジュラーなソリューションを作成することができます。 モジュールは を操作でき、完全にそれぞれ に更新されます。
• のアーティファクトを個別にバージョンアップすることができます。
• （あなたが もより簡単にきめの細かい.NETに セキュリティポリシーを管理することができます。たとえば、特定の ホストインスタンスのためにそれらを展開 、このような関連機能をグループ化することで、セキュリティやメモリ使用率 をよりきめ細かく制御 を容易にします より、 いくつかのアセンブリをデプロイするソリューションを使用することができます）。

解決策をデバッグするときに、複数のプロジェクトまたはソリューションサーフェスにソリューションを分割する際の主な欠点は、次のとおりです。 BizTalkソリューションのデバッグは、BizTalkを初めて使用する多くの開発者にとっては簡単ではなく、ソリューション間のバグを絞り込んでも簡単にはできません。ただし、ソリューションをより効果的に配置し、名前付け、ディレクトリ構造、名前空間の配置、関連する方法に関する標準を使用することで、この問題を解決できます。

他の欠点は、次のとおりです。 プロジェクト間

GACへの相互依存性は、配備に悪い整理に追跡 に難しいことができ 誤差を生じることが署名し、展開する

• もっとアセンブリ のソリューション。

プロジェクトの開始時（理想的には設計時）に、ソリューションの基本的な構成を設定するのに時間を費やす必要があります。ワンサイズのアプローチは存在しません。ソリューションが組織やクライアントに提供する機能の中で、開発、展開、および保守の際にソリューションをどのように管理するかについて考える必要があります。

開始するには、アーティファクトの種類または機能領域に基づいてソリューションを分割するのが適切です。ソリューションを拡張すると、アーティファクトの相互関係、強力なネーミング、セキュリティ、物理的な配置の管理方法をよりよく理解し、ソリューションをより効果的に配置できるようになります。このアプローチには注意が必要です。なぜなら、ソリューションの大部分を再配置しなければならなくなる可能性があります。これは、プロジェクトのタイムラインが厳しい場合に混乱を招く可能性があります。