Классический ASP для ASP.net или ASP.net MVC

У нас есть веб-приложение, которое разработано в классическом ASP, и за 5 лет оно превратилось в свою нынешнюю форму, которая насчитывает 100 страниц, огромную базу данных и более 10000 активных пользователей, ежедневно просматривая не менее 10 страниц.

Теперь мы хотели обновить его до последней версии .net. Первоначально мы думали переписать все приложение, но после анализа сценария мы обнаружили, что это нереальный вариант, также не предложенный многими экспертами. Мы еще не определились с тем, как это сделать иначе, но у нас возникли некоторые мысли о том, как добиться переписывания на лицах.

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

Вариант 2: На данный момент мы создали простой модуль и использовали его на классической странице ASP через IFrame, хотя пересылка данных между классическим ASP и новой страницей в IFrame была довольно сложной задачей.

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

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

Также хотелось бы знать, что использование ASP.net MVC поможет мне в этом?

ОБНОВЛЕНИЕ : Спасибо за ответы на ваши вопросы. Хотелось бы получить больше информации по обоим параметрам, указанным выше при переносе приложения с классического asp на asp.net или asp.net mvc. Было бы очень полезно для меня, если бы вы все могли через ваши взгляды, мнения и мысли по части миграции, а не с точки зрения выбора asp.net или asp.net mvc.

Позвольте мне начать со слов: «Я чувствую твою боль, брутха». Я прошел через это 3 года назад, и мне хотелось бы, чтобы к этому моменту MVC повзрослел, потому что разработанное мной решение WebForms довольно хорошо напоминает модель MVC, фактически не создавая библиотеки Microsoft для меня (конечно, было несколько вопиющих слов «Почему, черт возьми» неужели я делаю "различия").

Я также использовал iFrames для управления различиями в содержимом, используя .Net в качестве родительского приложения и классический asp в качестве подчиненного. Я разработал архитектуру фреймворка в .Net и реализовал это. Классические страницы asp затем «отбирались» из ненужных презентационных фрагментов (включает и еще много чего) и загружались в iFrames. Затем данные были переданы через URL с использованием специального шифрования. Чтобы убедиться, что аутентификация не может быть легко подделана, а доступ к странице осуществляется путем взлома строки запроса, мы также использовали в IIS обработчики Wildcard, которые заставляли .Net проверять подлинность перед анализом классических asp-страниц.

Учитывая это, я рекомендую немедленно отправиться в MVC.

1. MVC предоставит вам доступ к маршрутизации на уровне global.asax. С помощью умных манипуляций с контроллером вы можете разработать свои модели надлежащим образом и иметь общий контроллер, который обрабатывает все классические запросы asp по мере необходимости.
2. MVC упростит добавление тестового проекта и позволит вам проводить рефакторинг отдельных частей приложения на основе новой структуры модели, обеспечивая при этом достаточный охват тестами, чтобы убедиться, что вы все делаете правильно. Значение этого абсолютно неисчислимо, потому что при любом покрытии кода рефакторинга огромное беспокойство.
3. MVC придерживается более скриптового подхода к представлению, чем WebForms. WebForms пытается смешать все это, как будто это какое-то приложение с сохранением состояния (а это не так), и это может стать настоящим культурным шоком для людей, привыкших к классическому asp. Не поймите меня неправильно, ваши разработчики будут испытывать культурный шок, независимо от того, каким путем вы идете, но если вы справитесь с некоторыми из этих потрясений из уровня представления, вы можете добиться большего успеха.

Мне нравятся как WebForms, так и MVC (хотя я признаю, что с появлением Razor я немного склоняюсь к MVC). У них обоих есть свои места, и я думаю, что такое приложение, как вы описываете, может идеально подходить для реализации MVC, особенно с учетом «ступенчатой» природы, которую вам нужно будет использовать при развертывании переработанных частей приложения.

В любом случае, я думаю, вам нужно убедиться, что приложение .Net всегда является родительским приложением, когда дело доходит до аутентификации / авторизации / маршрутизации / и т.д. Мой коллега реализовал свою миграцию в аналогичном приложении с классическим asp в качестве родителя, и у него возникло множество проблем, когда наконец пришло время интегрировать все вместе.

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

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

Переход на ASP.NET MVC будет более трудоемким. Скорее всего, потребуется пересмотреть архитектуру вашей прикладной модели, чтобы она соответствовала шаблону MVC . Обычно это хорошая вещь, потому что она поощряет хорошее поведение, например, разделение интересов. Получившееся приложение вряд ли будет сильно напоминать все, что у вас есть, кроме основных логических частей. Вы получите и другие преимущества . Это будет большой культурный сдвиг, и потребуется некоторое (пере) обучение команды разработчиков, чтобы правильно понять, «как писать MVC».

Следует отметить, что Microsoft не отказывается от WebForms в соответствии с ScottGu (по состоянию на год назад), но я не думаю, что трудно сделать вызов, что если / когда они решат отказаться от одной из этих двух технологий, это будет WebForms.

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

Я настоятельно не рекомендую использовать WebForms в «больших» приложениях.

Мне нравится Вариант 1) (с MVC) намного лучше, чем Вариант 2), поскольку он позволяет вам постепенно развивать приложение, при этом не нужно соединять два приложения слишком сильно, как при использовании подхода iFrames.

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

Кроме того, определение соответствующих модулей для первой миграции может быть сложной задачей, но вы могли бы начать со всей новой функциональности, разрабатываемой в MVC, чтобы предотвратить перенос большего количества вещей в гараж. Затем, возможно, выберите разделы, в которых имеется значительное отставание в доработке или исправлении ошибок, которые необходимо выполнить дальше, так как приложение MVC станет формой рефакторинга с использованием вашей старой системы для получения ожидаемых результатов, как вы предлагаете. Не забудьте также воспользоваться тестируемостью MVC, добавив юнит-тесты и автоматические приемочные тесты (например, SpecFlow / Watin) во время этого рефакторинга. Одним из преимуществ последнего типа тестов является то, что вы можете проверить, что они проходят на старой системе, а затем применить те же тесты к вашему новому коду для этого и будущих рефакторингов.