Повторное использование кода - App_Code или BIN или UserControls?

Question

Недавно у меня была дискуссия на другом форуме с другим разработчиком, и тема была повторного использования кода в ASP.NET. Заявленный сценарий заключался в том, что ему необходимо часто обновлять код на серверах Production во время перерывов в работе сервера, и это приводит к тому, что сеанс становится сброшен для всех пользователей. Он избегает размещения общего кода или классов в папке App_Code или предварительно скомпилированных DLL в папку Bin, потому что любые обновления также обновят сеанс.

Решение, которое он придумал, заключается в том, чтобы поместить свой общий код в UserControls и ссылаться на них везде, где это требуется. Это позволяет ему обновлять только файлы UserControl, которые будут динамически перекомпилированы при следующем запросе без принудительного перезапуска сеанса. Обратите внимание, что в Usercontrols не предусмотрен какой-либо пользовательский интерфейс, они, вероятно, содержат только некоторую бизнес-логику.

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

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

Заранее спасибо.

Редактировать: Кроме того, было бы полезно, если бы кто-то мог точно определить, почему сеанс перезапускается в вышеупомянутых случаях.

Answer 1

Это действительно необычный подход, и настойчивый сеанс является очевидным ответом. Предполагая, что причины не использовать постоянную сессию являются законными, иногда вам просто нужно работать с любыми работами. Я хотел бы четко зафиксировать в исходных файлах необычное использование usercontrols и жить с ним.

Чтобы ответить на вопрос, почему сеанс получает сброс, отредактируйте. В процессе сеанса все данные сеанса находятся в памяти как часть вашего приложения. Различные изменения на веб-сайте (например, web.config и другие, которые я не помню с головы) заставляют приложение перезапускать все текущее состояние в вашем приложении. Сохранение на SQL или сервер сеанса сеанса процесса позволит приложению сбросить и потерять любое состояние, не затрагивая данные сеанса.

Answer 2

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

Answer 3

Могу ли я спросить, почему нет состояния сеанса, не входящего в состав процесса, на самом деле? Поскольку этот парень, похоже, прилагает все усилия, чтобы обойти эту «проблему», не лучше ли ему лучше искать решения? незавершенное состояние сеанса является единственным хорошим решением.

Answer 4

Я согласен с Деннисом, на самом деле нет проблем с переходом от inproc к государственному серверу. Не знаете, что такое ваши платформы разработчика/развертывания, но они должны включать службу состояния сеанса - запустите это, измените ваш web.config и проблема будет решена.

Answer 5

это умный (и некрасиво) решение общей задачи

Основной проблемой является архитектура такой системы; код, который необходимо обновить, может быть помещен в другую службу за пределами его веб-приложения, его код позади может затем вызвать эти услуги, а службы могут быть обновлены по мере необходимости, не затрагивая веб-приложение.

Answer 6

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

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