А>>>Никто на реальных бизнес-процессах Workflow Foundation не использует тут?
А>>>Как оно на практике выходит? Вы довольны им?
P_A>>Исполюзуем. Не довольны.
А>А можно чуть детальнее, чем больше всего раздражает?

Уже писали на прошлой неделе.

1. При сложном workflow стрелочек выходит очень много. Толку от визуальности нет — все сливается в кучу.
2. Нельзя сделать простой update-скрипт, т.к. оно хратится в сериализованном виде. В реальном проекте заказчики часто просят подкривить данные. Если бы было просто поле Status в БД и switch(Status) в коде — все просто. Изменил Status и все. А если статус хранится в виде сериализованного значения, то сделать простое переключение не получится.
3. Вспомогательного кода получается многовато
4. Обещенная возможность изменять workflow на живых данных оборачивается кучей кода. Относительно простого switch это слишком.
5. Совмещение в одной транзакции workflow, обычных объектов в коде и БД — можно, но опять же сложно. Если сверху еще и remoting, то совсем не приятно.

Каждый из пунктов победить можно, но в сумме — не понравилось. Впрочем может это как кошек — вполне вероятно мы еще не научились их готовить.

Никто на реальных бизнес-процессах Workflow Foundation не использует тут?
Как оно на практике выходит? Вы довольны им?

Здравствуйте, Аноним, Вы писали:

А>Никто на реальных бизнес-процессах Workflow Foundation не использует тут?
А>Как оно на практике выходит? Вы довольны им?

Исполюзуем. Не довольны.

Здравствуйте, Pavel_Agurov, Вы писали:

P_A>Здравствуйте, Аноним, Вы писали:

А>>Никто на реальных бизнес-процессах Workflow Foundation не использует тут?
А>>Как оно на практике выходит? Вы довольны им?

P_A>Исполюзуем. Не довольны.
А можно чуть детальнее, чем больше всего раздражает?

Здравствуйте, Pavel_Agurov, Вы писали:

P_A>Каждый из пунктов победить можно, но в сумме — не понравилось. Впрочем может это как кошек — вполне вероятно мы еще не научились их готовить.

то же самое + проблемы с производительностью.