Поддержка дизайнера WorkFlow с библиотекой классов - PullRequest
1 голос
/ 07 декабря 2008

Мне нужно добавить рабочие процессы в существующее решение, которое уже содержит библиотеку классов и веб-сайт. Если я добавлю рабочие процессы в библиотеку классов, где они логически подходят, у меня нет поддержки дизайнера. Если я создаю их в отдельном проекте, я склонен иметь круговые зависимости, потому что мои доменные объекты запускают рабочие процессы, а рабочие процессы нуждаются в моих доменных объектах.

Какая архитектура предпочтительнее, чтобы избежать этой проблемы?

Ответы [ 2 ]

2 голосов
/ 17 декабря 2008

Если я понимаю вашу проблему, она была бы решена, если бы у вас была поддержка конструктора WF в вашей библиотеке классов, чтобы вы могли добавить туда определения рабочих процессов?

Для этого вы можете отредактировать соответствующий файл проекта библиотеки классов (* .csproj для C #) и добавить следующие строки:

В первой группе недвижимости:

<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, вы также можете организовать свои сборки по-другому.

0 голосов
/ 10 декабря 2008

Способ решения этой проблемы состоит в том, чтобы разделить объект домена на сборку POCO (называемую Доменом) и сборку методов, которые работают с объектами POCO (называемые операциями). Это означает, что все другие сборки могут включать в себя объекты домена и таким образом передавать данные между собой. Таким образом, мои решения выглядят так (любая сборка может включать столько сборок, которые находятся ниже в списке)

  • сайт
  • рабочий
  • операция
  • 1010 домен * *
...