Переход с ASP Classic на .NET и уменьшение боли

Поверьте, я точно знаю, откуда вы. В настоящее время я переношу большое приложение с классического ASP на .NET .. И я все еще изучаю ASP.NET! : S (да, я в ужасе!).

Главное, что я держал в голове, это следующее:

• Я не отклоняюсь тоже от нынешнего дизайна (т. Е. Никакой массивный "позволяет вырвать ВСЕ это и сделать ASP.NET волшебным!" , это было бы очень опасно.Конечно, если вы уверены, вставайте :) Это всегда можно отредактировать позже.
• Сделайте резервную копию всего с помощью тестов, тестов и других тестов! Я действительно очень стараюсь войти в TDD, но очень сложно протестировать существующие приложения, поэтому каждый раз, когда я удаляю кусок классического и заменяю его на .NET, я гарантирую, что у меня есть как можно больше тестов зеленого света, поддерживающих меня.
• Много исследуйте, есть некоторые ГЛАВНЫЕ изменения между классической версией и .NET, и иногда то, что может быть много строк кода и включать в классический, может быть достигнуто в нескольких строках кода, подумайте перед кодированием .. Я Я усвоил это на собственном горьком опыте, несколько раз: D

Это очень похоже на игру в Jenga с вашим кодом :)

Желаем удачи с проектом, если есть вопросы, задавайте :)

После того, как я все закодировал, я сделаю несколько этапов рефакторинга / тестирования. Мне просто интересно, есть ли у кого-нибудь советы, как сделать этот процесс немного проще / эффективнее.

Обычно я не фанат TDD, но в случае рефакторинга это действительно правильный путь.

Сначала напишите несколько тестов, которые проверяют, что на самом деле делает бит, на который вы смотрите. Затем проведите рефакторинг. Это НАМНОГО надежнее, чем просто «похоже, что все еще работает».

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

Вы переходите от классического ASP к ASP с 3.5, просто не переписывая? Skillz. Мне приходилось иметь дело с некоторыми устаревшими ASP @work, и я думаю, что их проще проанализировать и переписать.

Страница ASP на 1500 строк? С множеством призывов включить файлы? Не говорите мне - у функций нет соглашения об именах, которое сообщало бы вам, какой включаемый файл имеет их реализацию ... Это возвращает воспоминания (дрожь) ...

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

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

Удачи!

Похоже, ты неплохо разбираешься в вещах. Я видел, как многие люди пытались выполнить прямую транслитерацию, включая и все такое, но это просто не сработало. Вам необходимо хорошо понимать, как ASP.Net хочет работать, потому что он сильно отличается от классического ASP, и похоже, что он у вас есть.

Для файлов большего размера я бы сначала попытался получить представление более высокого уровня. Например, я заметил одну вещь: классический ASP ужасно плохо относился к вызовам функций. Вы бы читали какой-то код и находили вызов функции, не имея ни малейшего представления о том, где она может быть реализована. В результате, классический код ASP имел тенденцию иметь длинные функции и сценарии, чтобы избежать этих неприятных скачков. Я помню, как видел функцию, которая распечатывала до 40 страниц! Анализировать такой объем кода - неинтересно.

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

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

Как ты догадался? ;)

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

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

Для файлов большего размера я бы сначала попытался получить представление более высокого уровня. Например, я заметил одну вещь: классический ASP ужасно плохо относился к вызовам функций. Вы бы читали какой-то код и находили вызов функции, не имея ни малейшего представления о том, где она может быть реализована. В результате, классический код ASP имел тенденцию иметь длинные функции и сценарии, чтобы избежать этих неприятных скачков. Я помню, как видел функцию, которая распечатывала до 40 страниц! Анализировать такой объем кода - неинтересно.

На самом деле у меня было довольно много неудовольствия работать с унаследованным кодом, поэтому у меня есть приличное понимание системы на высоком уровне. Вы правы насчет длины функции, есть некоторые процедуры (большинство из которых я реорганизовал в гораздо меньшие), которые в 3-4 раза длиннее любой из страниц aspx / вспомогательных классов / ORM на новом сайте.

Однажды я наткнулся на приложение .Net, которое было перенесено из ASP. Страницы .aspx были полностью пустыми. Для визуализации пользовательского интерфейса разработчики использовали StringBuilders в коде, а затем выполнили response.write. Это было бы неправильным способом!

Однажды я наткнулся на приложение .Net, которое было перенесено из ASP. Страницы .aspx были полностью пустыми. Для визуализации пользовательского интерфейса разработчики использовали StringBuilders в коде, а затем выполнили response.write. Это было бы неправильным способом!

Я видел, как это было сделано по-другому, код страницы был пустым, за исключением объявления глобальных переменных, тогда VBScript был оставлен в ASPX.