Влияние на производительность при использовании WF для управления навигацией пользовательского интерфейса в приложении ASP.NET MVC

Question

Мне нужно создать веб-приложение с различными потоками процессов и различными этапами пользовательского интерфейса в зависимости от локали вошедшего в систему пользователя.

Я разработал ряд приложений ASP.NET на C #, и, как и разделение задач, подход MVC дал бы мне. Поэтому я смотрю на использование этих технологий.

Самое главное, что разные пользователи в разных локалях должны иметь разный опыт, несмотря на доступ к одному и тому же источнику данных. Я также ограничен требованием иметь возможность легко настраивать новые потоки процессов. Windows Workflow Foundation на основе XAML выглядит хорошим кандидатом и позволил бы мне избежать разработки собственного механизма потока процессов.

Однако меня немного беспокоит влияние такого подхода на производительность. Кто-нибудь пробовал такую ​​архитектуру? Какое влияние я могу ожидать на время запроса, загрузку ЦП и потребление памяти?

Все мнения с благодарностью получены, Спасибо.

Answer 1

Howdo

Принципиальное возражение и, я полагаю, риск для производительности, который, хотя и не связан конкретно с вашим запросом, заключается в том, что рабочий процесс Windows не был разработан для этого типа сценария. Проще говоря, первый принцип разработки WF состоял в том, чтобы обеспечить выполнение длительных транзакций, построенных на основе веб-сервиса и SOA, то есть транзакционного подключения в течение нескольких дней, и поэтому его время выполнения оптимизировано для него. На самом деле он не очень подходит, особенно когда вам нужно будет заставить его работать, и он будет гораздо более ресурсоемким для коротких рабочих процессов, т. Е. В отношении изменений состояния, кэширования и т. Д. С точки зрения сопоставимых другой код процесса / двигатели. Если вы все же продолжите, запустите пилот и запустите его до смерти, используя Mercury Load Runner.

scope_creep