クラス ライブラリと Web サイトが既に含まれている既存のソリューションに、ワークフローを追加する必要があります。ワークフローが論理的に適合するクラス ライブラリにワークフローを追加すると、デザイナーによるサポートはありません。別のプロジェクトでそれらを作成すると、ドメイン オブジェクトがワークフローを実行し、ワークフローがドメイン オブジェクトを必要とするため、依存関係が循環する傾向があります。
この問題を回避するために推奨されるアーキテクチャは何ですか?
クラス ライブラリと Web サイトが既に含まれている既存のソリューションに、ワークフローを追加する必要があります。ワークフローが論理的に適合するクラス ライブラリにワークフローを追加すると、デザイナーによるサポートはありません。別のプロジェクトでそれらを作成すると、ドメイン オブジェクトがワークフローを実行し、ワークフローがドメイン オブジェクトを必要とするため、依存関係が循環する傾向があります。
この問題を回避するために推奨されるアーキテクチャは何ですか?
私があなたの問題を理解していれば、クラス ライブラリに WF のデザイナー サポートがあれば解決されるので、そこにワークフロー定義を追加できますか?
対応するクラス ライブラリ プロジェクト ファイル (C# の場合は *.csproj) を編集して、次の行を追加します。
最初の PropertyGroup で:
<ProjectTypeGuids>{14822709-B5A1-4724-98CA-57A101D1B079};{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}</ProjectTypeGuids>
ファイルの下部:
VS2008 の場合:
<Import Project="$(MSBuildExtensionsPath)\Microsoft\Windows Workflow Foundation\v3.5\Workflow.Targets" />
VS2005 の場合:
<Import Project="$(MSBuildExtensionsPath)\Microsoft\Windows Workflow Foundation\v3.0\Workflow.Targets" />
プロジェクトが IDE に再ロードされると、WF のサポートが得られます。
しかし、gbanfill が述べたように、アセンブリを別の方法で編成することもできます。
この問題を回避する方法は、ドメイン オブジェクトを POCO アセンブリ (ドメインと呼ばれる) と、POCO オブジェクトに対して処理を行うメソッドのアセンブリ (操作と呼ばれる) に分割することです。これは、他のすべてのアセンブリにドメイン オブジェクトを含めて、それらの間でデータを渡すことができることを意味します。したがって、私のソリューションは次のようになります(アセンブリには、リストの下にあるアセンブリをいくつでも含めることができます)