Где используется Windows Workflow Foundation?

Используется ли WF на пользовательском интерфейсе или бизнес-уровне? Если на уровне пользовательского интерфейса нужно ли кому-то кодирование на бизнес-уровне даже использовать или узнать его?

Ответ 1

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

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

EDIT:

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

Если вы считаете, что использование WF для вашего небольшого проекта обеспечит ценную отдачу от инвестиций, то идите на это. Вам необходимо как вернуть первоначальные затраты на обучение, инфраструктурную реализацию и развертывание, так и обеспечить долгосрочную и осязаемую экономию средств, просто нарисуя код для решения проблем. Я сомневаюсь, что WF предложит небольшой проект такой рентабельности инвестиций. Для крупных проектов или нескольких интегрированных проектов для одной крупной компании гораздо проще реализовать ROI, чем с меньшими проектами, поэтому платформы рабочего процесса, такие как WF, обычно используются только в этом масштабе.

Ответ 2

WF - это интерфейс к слою buisness.

Рабочие процессы - это декларативный способ написания программ путем связывания заранее определенных действий, а не императивной модели программирования написания строк кода. Кроме того, у вас есть много графических инструментов, которые позволяют вам обрабатывать рабочие процессы. shuch как черная жемчужина, K2 и дизайнер sharepoint.

Они очень используются и хорошо изучают. Я начал использовать то в sharepoint и ms crm. Теперь я всегда смотрю на рабочие процессы для решения моих общих проблем.

вот несколько ссылок: mirosoft msdn.microsoft.com/en-us/netframework/default.aspx Wkik: http://en.wikipedia.org/wiki/Windows_Workflow_Foundation

Ответ 3

WF в основном понимается весьма императивно - последовательность хронологических событий.

Однако, если вы углубитесь глубже, вы можете комбинировать действия по-разному. Хорошим примером являются рабочие процессы на уровне штата, которые обычно также отображаются при представлении WF. WF позволяет помещать Workflow в режим ожидания: текущее состояние сохраняется и перезагружается один раз, например. происходит внешнее событие. Таким образом, рабочие процессы могут быть полезны при отслеживании длительных взаимодействий, в которых система должна ждать, например. для завершения какого-либо внешнего процесса или для взаимодействия какого-либо пользователя с системой.

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

С моей точки зрения, однако, примечательно, что WF является продуктом версии 1: существует ряд неудобных вещей, которые могут привести вас к коду, который трудно поддерживать, части инфраструктуры довольно сложны Вы можете найти некоторые несоответствия API здесь и там.

Существует также руководство о том, что вы не должны делать, если хотите когда-либо переносить свои рабочие процессы в следующее поколение WF.