Генерируем PDF из HTML-шаблона с условиями, при помощи wkhtmltopdf и RazorEngine

[lair]

И какая религия вам не позволяет использовать RazorPDF? И не плодить временных файлов и процессов на веб-сервере…

[Newbilius]

Религия «я о нём не знал, но спасибо комментариям на Хабре, которые всегда выведут на путь истинный!».

Надо только будет сравнить качество и скорость генерации. Отсутствие глюков там.

[Newbilius]

Правда, я пока не смог понять, как результат работы RazorPDF (т.е., PDF-файл) сохранить на сервер. Сразу отдать то его просто, но этой то задачи как-раз не стояло.

[lair]

В рамках asp.net не может стоять задачи «сохранить сгенеренный файл на сервер», это нарушение декомпоновки слоев.

[Newbilius]

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

[lair]

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

(если это кэш, конечно)

[Newbilius]

Файл можно конвертировать, делать публичным, собирать в единый архив с другими… Запросы будут разные, кэш — у каждого свой
Хотя, идею я вашу, похоже, понял.

[lair]

Понимаете ли, в вашей изначальной задаче ничего этого не было.

[Newbilius]

Резонно! Подправил условия, добавив очередной пункт.

[lair]

В этих условиях («результат работы должен сохраняться в файл для возможности дальнейшего им манипулирования») нужно выкидывать asp.net и делать работу на сервисах и очередях.

[blood_develop]

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

[lair]

Возможно, в системе, где надцать сервисов WCF, которые собираются и разворачиваются вручную, сначала надо подумать о том, как это вообще дальше поддерживать. Потому что там любая доработка - лишняя морока.