Как перенести существующее приложение asp.net в формат шаблона asp.net MVC - PullRequest
37 голосов
/ 10 февраля 2009

Я хочу перенести существующее приложение ASP.NET в формат шаблона ASP.NET MVC. Какой процедуре я должен следовать? Любые пошаговые инструкции были бы очень полезны.

Ответы [ 4 ]

70 голосов
/ 24 февраля 2009

Это мое пошаговое руководство, основанное на шагах, которые мы предприняли в моей компании при переходе от классической веб-формы 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 для обхода обработки этих папок как маршрутов.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2 голосов
/ 27 августа 2017

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

  • Заменить <% - теги комментария на @ *</li>
  • используйте @ RenderSection ("Footer", false) для @section footer {} и т. Д., Если у вас есть дополнительные ContentPlaceHolder , кроме основного тела в представлении который RenderBody ().

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

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

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

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

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

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

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

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

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

...