Интеграция / переход на MVC3 из WebForms с большой существующей библиотекой пользовательских элементов управления - PullRequest
4 голосов
/ 05 августа 2011

Вот ситуация.Мы добавляем новое приложение в наш набор веб-приложений, основанных на WebForms, и поэтому я подумал, что сейчас самое время представить MVC.

Я провел все исследования по объединению двух, и все проект был настроен с использованием Area, который использует маршруты MVC, в то время как остальная часть проекта (visual studio) работает с веб-формами так, как работает..

Главные страницы были преобразованы в макеты Razor, что не так уж и плохо, потому что для каждого приложения была доступна только одна мастер-страница.

Проблема, с которой я столкнулся, - это повторное использование пользовательских элементов управления.,У нас есть десятки пользовательских элементов управления, многие из которых довольно сложные, которые используются во всех наших приложениях.Большинство из них (особенно те, которые было бы трудно портировать) делают изрядную сумму с ViewState и postbacks.

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

Моя интуиция говорит, что на самом деле нетхорошее решение, и нам, возможно, придется отказаться от идеи пойти в MVC для этого проекта и придерживаться веб-форм, но я хотел посмотреть, есть ли у сообщества SO какое-либо понимание того, что делать в этом сценарии.

1 Ответ

4 голосов
/ 07 августа 2011

Если у вас есть бюджет, чтобы переписать эти элементы управления на стороне сервера, используя парадигму MVC, это будет наилучшим способом.Если нет, вы все равно могли бы встраивать их в существующие классические страницы WebForms, которые могли бы взаимодействовать с новым приложением MVC, используя стандартные методы HTTP / HTML: формировать сообщения, отправлять идентификаторы через параметры строки запроса, iframes, файлы cookie, хранилища HTML 5 и т. Д.Хотя одно можно сказать наверняка: постарайтесь не включать эти элементы управления на стороне сервера в свои представления MVC.В итоге вы получите какое-то гибридное приложение, которое не является ни надлежащим ASP.NET MVC, ни подходящими веб-формами, что может привести к катастрофе.

Лично мне приходилось выполнять одну и ту же миграцию несколько раз, и я не стал смешивать классическиеWebForms с MVC в том же приложении, используя области или другие методы.В конце дня это может превратиться в кошмар, пытаясь заставить этих двоих существовать вместе.Это всегда одно из двух: у меня есть бюджет, и я переписываю с нуля правильно, или у меня нет бюджета, и я делаю новые вещи правильно, используя ASP.NET MVC, и пытаюсь взаимодействовать с существующим приложением.

Мне проще просто запустить отдельное приложение MVC, которое в зависимости от того, какое взаимодействие я ищу, будет использовать разные методы для интеграции функциональности из существующего приложения WebForms.

Я не совсем знакомсо сложностью и деталями вашего сценария, поэтому трудно дать объективный ответ, но хорошая возможность продолжить писать новый код на основе существующих серверных элементов управления WebForms и вообще не использовать MVC для этого проекта.,Написание нового приложения на ASP.NET MVC просто ради него не всегда может быть лучшим выбором.

...