Сравнение между Stateless (в коде google) и Windows Workflow

Я начинаю думать, что я должен расколоть Windows WF в пользу чего-то более простого. Мне не обязательно приостанавливать выполнение рабочего процесса в течение длительных периодов времени и восстанавливать их позже. Я бы хотел, чтобы простая система состояний, у которой есть базовое suspend/resume/abort (без сериализации).

Я загрузил Faceless framework из Google Code и собираюсь начать с ним играть, но хотел бы услышать, что другой .NET программисты там используют.

РЕДАКТИРОВАТЬ. Безгосударственный кажется очень простым в реализации, но я действительно задаюсь вопросом, правильно ли это для конфеты. В автоматизации я всегда чувствую противоречие в отношении использования государственных машин. Хотя я использую термин "конечный автомат", я делаю это свободно, потому что я использую его больше как блок-схему. Вместо использования состояний для представления текущего режима, в котором находится машина, я использую его для выполнения функций. Поэтому в этом случае с помощью Stateless я бы фактически использовал переход из одного состояния в другое как механизм для вызова функций в моем контроллере автомата для конфет. Мысли?

Ответы

Ответ 1

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

Stateless

Доводы

  • с открытым исходным кодом
  • синтаксически сжатый и легко читаемый
  • довольно хорошие примеры в Mercurial repo на google code
  • Я могу очень быстро перевести диаграмму состояния UML в код, используя stateless.
  • Государственное обслуживание очень простое - я могу легко и легко добавлять и удалять. Методы расширения позволяют мне настраивать состояния на отдельных строках, поэтому я могу прокомментировать триггеры или действия, которые я не хочу использовать.
  • передача данных в/из конечного автомата выполняется легко, и вы можете сделать это, как бы вы ни захотели в коде.
  • Аналогично, конечный автомат может обновлять графический интерфейс различными способами. Прямо сейчас, я изменяю данные через интерфейс, а затем GUI использует таймер для обновления своих элементов. Я также мог бы использовать BackgroundWorker для этого.
  • Я только начал использовать субтитры для обработки моего графического интерфейса, которому необходимо управлять различными состояниями, такими как Running, Paused, Aborted и Idle. Состояние приостановлено, потому что пользователь может приостановить систему различными способами, но триггеры резюме зависят от способа их приостановки. Мне нравится управлять возможностью включения/отключения графического интерфейса пользователя и всплывающими подсказками, используя легкую систему состояний машины.

против

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

Windows Workflow Foundation

Доводы

  • графический подход к разработке рабочего процесса
  • поддержка сохранения, приостановка, возобновление, прерывание рабочих процессов
  • MS, вероятно, имеет большую команду программистов для поддержки этого
  • GUI позволяет легко отключать/повторно активировать действия

против

  • графический подход к разработке рабочего процесса скрывает тот факт, что эта вещь довольно сложная.
  • чтобы использовать постоянство и получить паузу/возобновить/прервать, вам нужно установить и настроить "службу сохранения", что-то, что мне еще предстоит выяснить, как работать. Я могу настроить базу данных SQL, но во время выполнения я получаю кучу ошибок, которые я не понимаю.
  • потому что это от MS, вы не знаете, будет ли он слишком долго или полностью отбросить.
  • обработка ошибок немного странная, потому что вы можете использовать код позади или FaultHandler
  • передача данных из WF в основное приложение сложна и требует чего-то вроде WCF (другая технология, которой у меня недостаточно времени, чтобы учиться адекватно прямо сейчас) или используйте интерфейс ExternalDataExchange.