Нарушение производительности при помещении классов в коде aspx и ascx

Question

Какое снижение производительности при определении классов в коде позади aspx / ascx вместо того, чтобы предварительно скомпилировать их в dll? Я знаю, что это не лучшая практика, и с этим связаны многочисленные проблемы (например, сложный модульный тест, код не пригоден для повторного использования и т. Д.), Но он очень удобен, когда вы имеете дело с классами, которые требуют изменяться на лету несколько раз в день, поскольку эти изменения не потребуют какого-либо перезапуска приложения (например, изменения App_Code, обновление dll в папке bin).

Answer 1

нет

"Нет." Классы codebehind скомпилированы в DLL на лету, а затем эта DLL сохраняется. Так что в основном при первой загрузке страницы будет небольшая задержка, но после этого скорость должна быть такой же, как и у скомпилированных классов.

Answer 2

Сопутствующий ущерб - сброс сеанса

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

Answer 3

Выбор использования динамической компиляции или скомпилированных DLL действительно зависит от того, насколько организован ваш процесс выпуска. Если ваше приложение плотно скомпилировано в библиотеки DLL, вы можете ожидать, что вы проверили ошибки сборки и ожидаете, что все будет более надежным при выпуске. С динамической компиляцией у вас есть возможность обмениваться файлами .cs на лету (например, drag & drop, ftp). Это означает, что вы можете быть более проворным, но у вас может не быть того дополнительного шага уверенности, который помог бы вам знать, что вы держите сборку без изменений.

Answer 4

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

Answer 5

Я не верю, что после начальной динамической компиляции действительно наблюдается снижение производительности (что произойдет при первом обращении к странице, кодовая часть которой была изменена). Как вам пришлось менять классы несколько раз в день? Это было бы отстой!

EDIT: Я должен был добавить, что это не должно влиять на юнит-тесты или повторное использование кода, как вы заявили. Ничто не мешает вам развертывать не скомпилированный сайт в целях сопровождения, в то же время имея возможность запускать модульные тесты, развертывать скомпилированные сборки для других проектов (при необходимости) и т. Д. Во время регистрации / сборки.

Однако, если вы не используете систему контроля версий и не имеете автоматической сборки, тогда возникает совершенно новая проблема. Члены нашей команды использовали для редактирования файлов CODE непосредственно на производственных серверах. вздрагивает