Как перенести существующее приложение asp.net в формат шаблона asp.net MVC

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

Этапы: 1. Планирование — переход на MVC с веб-форм в ASP.Net требует тщательного планирования. Ошибка, которую мы совершили в нашем движении, заключается в том, что мы не понимаем, что на самом деле на этом этапе планирования есть два аспекта: планирование маршрута и планирование модели/контроллера/действия. Если этого не сделать, позже возникнут серьезные проблемы, когда вы попытаетесь расширить функциональность своего сайта или выполнить более сложные миграции.

Советы: - Посмотрите на свою текущую карту сайта и спроектируйте улучшенную структуру карты сайта/каталога для использования в приложении ASP.Net MVC. Выясните «язык» для вашего веб-сайта, например. поведение по умолчанию ASP.Net MVC состоит в том, чтобы иметь http://sitename/{controller}/{action}/{id }, но вы можете переопределить его, когда наберетесь опыта взлома правил маршрутизации.

• Помните, что по умолчанию каждый контроллер будет перенаправлен через виртуальный подкаталог вашего приложения, например. http://sitename/X будет перенаправлен на XController (и по умолчанию его метод Index), http://sitename/Y/Get будет перенаправлен на метод Get() YController. Вы можете изменить это по своему усмотрению (маршрутизация действительно мощная), но это выходит за рамки этого ответа.

• Используя существующую карту сайта, укажите, в какую папку в структуре MVC должна попадать каждая текущая страница .aspx (конечно, сначала поинтересуйтесь, должна ли она вообще существовать).

• Если сценарии, изображения и т. д. не хранятся вместе или в некоторых папках с «зарезервированными именами» в каждом подкаталоге, рассмотрите возможность сделать это сейчас, когда вы переделываете дизайн. Это связано с тем, что это значительно упростит ваш дизайн, позволяя использовать команду правила маршрутизации Map.IgnoreRoute() в файле Global.aspx.cs, чтобы обойти обработку этих папок как маршрутов.

В нашем случае мы отразили реальный макет подкаталога текущего сайта, где каждый подкаталог стал контроллером, например. /Account будет иметь AccountController, /X будет иметь XController. Все страницы, попавшие туда, были заменены действиями внутри каждого контроллера. например http://sitename/profile/about.aspx теперь стал http://sitename/profile/about и сопоставляется с методом ActionResult "about" внутри profileController. Это позволяет нам оставаться гибкими, выполняя частичную миграцию одного или двух каталогов (или нескольких файлов внутри одного каталога) в течение серии спринтов, вместо того, чтобы мигрировать весь сайт за один раз в течение гораздо более длительного времени.

2. Создайте новое приложение ASP.Net MVC в Visual Studio и немедленно создайте правила в файле Global.asax, которые игнорируют правила маршрутизации для папок, существующих на текущем сайте.

3. Скопируйте папки из веб-приложения ASP.Net в папки приложения ASP.Net MVC. Запустите веб-сайт и убедитесь, что он работает правильно (так и должно быть, поскольку правила маршрутизации еще не используются).

4. Выберите подкаталог или подмножество файлов в подкаталоге для переноса.

5. Для каждой страницы .aspx в этом подкаталоге:

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

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

   в. Создайте контроллер, если он еще не создан, и поместите соответствующий метод ActionResult для действия, которое, согласно вашему плану, должно направляться в это представление. Если вы обнаружите, что есть новое действие, которое не сопоставляется со страницей со старого сайта, создайте представление для контроллера и включите соответствующие теги //TODO:, чтобы вы могли отслеживать это, чтобы реализовать после того, как вы перенесли существующие страницы.

   д. Рассмотрите возможность добавления некоторого кода обработки для неизвестных действий, если у вас еще нет правила маршрутизации {*catchall} для этого в вашем файле global.asax.cs.

   е. Создайте классы конструктора для Модели, чтобы с учетом определенных параметров, которые будет иметь Контроллер (переданных как ваш {id} или, возможно, параметр Request.QueryString из URL-адреса, HTTP-заголовка или файла cookie), Модель будет знать, как обратиться к существующим классам бизнес-логики и создать себя для рендеринга в представлении.

   ф. Перейдите к следующей странице в списке и снова начните с шага а.

6. Наконец, создайте правило маршрутизации, которое будет вызывать ваш новый контроллер и позволит реализовать написанные вами действия. Отладка, отладка, отладка... Если вы уверены, что все в порядке, удалите существующую папку и файлы, которые вы перенесли с основного сайта, а также правило IgnoreRoute в файле global.asax.cs.

7. Создайте перенаправление любым удобным для вас способом, если вы хотите сохранить старые имена каталогов и файлов для непрерывности (например, пользователи уже могли добавить в закладки определенные страницы на старом сайте).

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

Совет: серьезно рассмотрите возможность использования такого инструмента, как RouteDebug для маршрутизации отладки, чтобы вы могли выяснить странные вещи, подобные приведенным выше, или когда у вас есть несколько правил маршрутизации, которые срабатывают и вызывают неожиданное поведение.

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

Пусть эти несколько дополнительных советов помогут

• Замените ‹%-- теги комментариев на @*

• используйте @RenderSection("Footer",false) для нижнего колонтитула @section { } и т. д., если у вас есть дополнительные ContentPlaceHolder, кроме основного тела в представлении, которое Рендерное тело() .

• все старые нормальные теги runat="server" безвредны и не мешают компиляции и могут быть впоследствии очищены

• все элементы управления Видимость, которая легко контролировалась в коде и разметке (Visible="True") и контролировалась в code_behind с помощью идентификатора элемента управления, должна быть реорганизована в ViewBag Collection и < strong>@if блокирует в представлении Razor.

• вы также можете посмотреть этот отличный курс Pluralsight по этой теме (3 часа 49 минут)

  • Rebuilding Web Forms Applications in MVC

Я не думаю, что существует такая вещь, как «пошаговая миграция» с ASP.NET WebForms на ASP.NET MVC. Это два совершенно разных паттерна проектирования, построенных на одном фреймворке, но есть (в большинстве случаев) много вещей, которые нужно не просто перенести, а полностью перепроектировать, если вы не хотите просто строить веб app в проекте шаблона MVC вместо шаблона WebForms.

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

Мой ответ будет "Вы не" :). Если вы действительно хотите это сделать, вы можете использовать текущий сайт asp.net в качестве конечной цели или в качестве «документа» требований. И, возможно, вы можете использовать слой данных в своей модели, но вам придется переделывать весь сайт.

Как уже указывал Томас, он ОЧЕНЬ отличается от классического asp.net.