Повторное использование кода - App_Code или BIN или UserControls? - PullRequest
2 голосов
/ 05 февраля 2009

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

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

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

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

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

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

Ответы [ 6 ]

2 голосов
/ 05 февраля 2009

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

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

2 голосов
/ 05 февраля 2009

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

2 голосов
/ 05 февраля 2009

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

1 голос
/ 05 февраля 2009

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

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

1 голос
/ 05 февраля 2009

это умное (и безобразное) решение общей проблемы

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

1 голос
/ 05 февраля 2009

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

...