C # ASP.NET, WebForms для MVC: есть ли смысл менять в нашем случае?

Question

У нас есть веб-приложение на основе WebForms со следующими свойствами:

Платформа для больших бизнес-объектов (сплоченная проверка DAL / бизнес-объекты / проверка на стороне сервера, похожая на CSLA), предварительно скомпилированная и помещенная в папку Bin.Использует много UserControls.

Глядя на обзоры MVC, кажется, что существует четкое разделение того, как разделен код, нет состояния сеанса (что выглядит странно, но, возможно, нормально, если сайт в основномобслуживающий контент?), и кажется, что создание страниц выглядит как классический asp (использование тегов <%%>)

Есть ли у меня неправильная интерпретация MVC?Является ли MVC просто специфической архитектурой, или как все пойдет, и WebForms в конечном итоге будут отброшены?Как можно разделить MVC, когда существует существующий Business Object Framework?Почему нет состояния сеанса?Работают ли UserControls в MVC?

Я понимаю, что это может быть субъективно, поэтому в основном ищу ваши комментарии по этому вопросу, чтобы составить свое мнение.

Answer 1

MVC на 90% + то же самое, что и веб-формы, но, конечно, когда у всех возникают дебаты, они, как правило, забывают об этом.

Под слоями может быть столько слоев, сколько нужно для предоставления данных, и да, вы можете использовать стиль UserControl. Это скорее изменение мышления, чем изменение технологии. У MVC есть свои преимущества, он заключает в себе тот факт, что HTTP это состояние . Webforms до некоторой степени абстрагируют этот факт, что также упрощает некоторые вещи (например, viewstate). Состояние сеанса, компиляция ... все это есть, оно в одной структуре под обоими.

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

Я бы не стал запускать другой проект в WebForms, но это me , и что мне нравится ... вам действительно нужно выяснить, что для вас более естественно, и, если применимо, ваша команда.

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

Answer 2

Похоже, у вас есть большая связь между вашей моделью домена и вашей презентацией. Если бы это было так, потребовалось бы значительное количество реархитектуры. MVC поддерживает состояние сеанса, но не использует ViewState - похоже, у вас есть некоторая путаница. Он не поддерживает обычные пользовательские элементы управления или что-либо, что зависит от ViewState. Вы можете создавать «элементы управления» для MVC (называемые «частичными» представлениями), чтобы функциональность была, но в другой форме. В MVC ваши представления очень отделены от вашей бизнес-модели, как правило, у вас будет набор моделей для конкретных представлений, которые являются посредниками между ними, и представления строго привязаны к модели представления, а не к бизнес-модели.

Хотя я бы порекомендовал MVC как лучшую архитектуру для веб-приложений, в вашем случае я не уверен, что имеет смысл переключаться (по крайней мере, сейчас). Я бы порекомендовал либо придерживаться WebForms (который не исчезнет, ​​согласно Скотту Хансельману), либо медленно перемещать детали, начиная с новых функций (или приложений), в MVC.

Answer 3

MVC - это новая блестящая бутылка для того же старого вина, которое является паутиной и как она работает.

С другой стороны, вы, наконец, можете отойти от состояния просмотра asp.net и жизненного цикла страницы, обратных передач, сумасшедших URL и т. Д.

Если вам нужно перейти от веб-форм к MVC, посмотрите на зависимость от сторонних элементов управления, которые вы могли использовать в пользовательском интерфейсе приложения. Не все поставщики пока имеют эквиваленты MVC. Сессии и ViewState - это другие наиболее важные аспекты, на которые стоит обратить внимание в конце пользовательского интерфейса. Если у вас есть общедоступное веб-приложение, подумайте о закладке URL-адреса. Все это может быть дополнительными факторами, на которые следует обратить внимание при переходе на MVC.

Как правило, я бы рекомендовал сначала разложить ваш код на уровень Model-Controller и, как только он будет завершен, а затем изменить UI на View и использовать механизмы маршрутизации URL-адресов MVC. В качестве альтернативы вы можете использовать любой приличный модуль перезаписи URL-адресов и сначала опубликовать URL-адрес в стиле REST, переписать старый URL-адрес в новый URL-адрес, а затем медленно преобразовать разделы приложения в MVC.