C# ASP.NET, WebForms к MVC: имеет смысл изменяться в нашем случае?
У нас есть основанное на WebForms веб-приложение с этими свойствами:
Платформа Объекта Крупного бизнеса (Близко вяжет DAL / Бизнес-объекты / Проверка Серверной стороны, подобная CSLA), Предварительно скомпилированный и помещенный в папку Bin. Использование много UserControls.
При рассмотрении обзоров MVC, которым это кажется, существует отличительное разделение о том, как код разделен, нет никакого Состояния сеанса (который кажется нечетным, но возможно хорошо, если веб-сайт, прежде всего, служит содержанию?) и это появляется, создавая взгляды страниц, подобные классическому asp (использование <% %> теги)
У меня есть неправильная интерпретация MVC? MVC является просто определенной архитектурой или является способом, которым будут идти дела, и WebForms будет в конечном счете отброшен? Как каждый разделяет M-V-C, когда существующая Платформа Бизнес-объекта существует? Почему не там никакое состояние сеанса? UserControls работают в MVC?
Я понимаю, что это могло быть субъективно, поэтому главным образом ища Ваши комментарии к предмету для создания моего моего собственного ума.
3 ответа
Я не собираюсь обновлять приложения до 3.
Однако я только что решил, что все новые проекты будут железными дорогими3. Отсутствие поддержки плагинов не является большой проблемой, так как я вижу это как возможность отделить мои приложения от плагинов, чтобы я мог поменять их в и из, как я прошу позже.
Я также подозреваю, что большие плагины будут обновляться очень быстро, так как они не захотят оставаться в пыли.
Отслеживайте состояние плагина здесь.
-121--3653479-Что бы вы ни делали, не печатайте XML!
См. HOWTO Избегайте вызова бозо при создании XML
-121--1734827-MVC на 90% + совпадает с WebForms, но, конечно, когда все ведут дебаты, они, как правило, оставляют этот tid-bit out.
Ниже может быть столько слоев, сколько требуется для предоставления данных, и да, можно использовать стиль UserControl. Это скорее изменение мышления, чем изменение технологии. MVC имеет свои преимущества, он охватывает тот факт, что HTTP не имеет состояния . Веб-формы в определенной степени абстрагируют этот факт, что также облегчает некоторые вещи (например, состояние просмотра). Состояние сеанса, компиляция... это все там, это в одной и той же структуре под обоими.
Короче говоря: используйте то, что хотите, хорошо исследуйте (примеры проектов есть везде). Если вы находитесь глубоко в проекте, коэффициент времени для изменения, это кривая обучения, а также фактическое время кода. Это решение зависит от вас и вашей команды , если оно слишком отличается, то оно может быть не очень полезным, потому что есть некоторая корректировка. Если вам удобнее с новой технологией, MVC может быть намного чище... оба по-прежнему используются.
Я бы не начал другой проект в WebForms, но это я , и то, что мне удобно... вы действительно должны выяснить, что чувствует себя более естественно для вас, и, если применимо, вашей команды.
Кроме того, tvanfosson сделал отличную точку зрения: чем больше валидации или действительно какой-либо пользовательской логики, которая была в веб-проекте раньше, тем больше времени нужно, чтобы перейти. Если у вас уже есть отличное разделение слоев, вы в гораздо лучшем положении, чтобы сделать это, если нет, это еще один важный момент.
MVC - это новая блестящая бутылка для того же старого вина, которое представляет собой Интернет и то, как оно работает.
С другой стороны, вы, наконец, можете отказаться от состояния просмотра asp.net и жизненного цикла страницы, постбэков, сумасшедших URL-адресов и т. Д.
Если вам нужно перейти от веб-форм к MVC, обратите внимание на зависимость от сторонних элементов управления который вы могли использовать в пользовательском интерфейсе вашего приложения. Не все производители пока имеют эквиваленты MVC. Сеансы и ViewState - другие наиболее важные аспекты, на которые следует обратить внимание со стороны пользовательского интерфейса. Если у вас есть общедоступное веб-приложение, подумайте о том, что URL-адрес добавлен в закладки. Все это может быть дополнительными факторами, которые следует учитывать при переходе на MVC.
Как правило, я бы рекомендовал сначала разложить ваш код на уровень модель-контроллер, а как только это будет завершено, затем изменить пользовательский интерфейс на просмотр и использовать механизмы маршрутизации URL-адресов MVC. В качестве альтернативы вы можете использовать любой достойный модуль перезаписи URL-адресов и сначала опубликовать URL-адрес в стиле REST, переписать старый URL-адрес на новый URL-адрес, а затем медленно преобразовать разделы вашего приложения в MVC.
Похоже, у вас много взаимосвязей между вашей моделью предметной области и вашей презентацией. Если это так, потребуется значительное изменение архитектуры. MVC поддерживает состояние сеанса, но не использует ViewState - похоже, вы немного запутались. Он не поддерживает обычные UserControls или что-либо, что зависит от ViewState. Вы можете создать «элементы управления» для MVC (называемые «частичными» представлениями), чтобы функциональность была там, но в другой форме. В MVC ваши представления сильно отделены от вашей бизнес-модели, как правило, у вас есть набор моделей для конкретных представлений, которые являются посредниками между ними, и представления строго типизированы для модели представления, а не для бизнес-модели.
Хотя я бы рекомендовал MVC как лучшую архитектуру для веб-приложений, в вашем случае я не уверен, что имеет смысл переключаться (по крайней мере, сейчас). Я бы рекомендовал либо придерживаться WebForms (которые, по словам Скотта Хансельмана, не исчезнут), либо медленно переносить части, начиная с новых функций (или приложений), на MVC.