Миграция с ASP Classic на .NET и уменьшение боли

Question

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

На главной странице нашего раздела принятия предложений 1500 строк, около 90% из которых - ASP, и, вероятно, еще 1000 строк в вызовах функций для включений. Я думаю, что 1500 строк тоже немного обманчивы, так как мы работаем с такими драгоценными камнями, как этот

function GetDealText(sUSCurASCII, sUSCurName, sTemplateOptionID, sSellerCompany, sOfferAmount, sSellerPremPercent, sTotalOfferToSeller, sSellerPremium, sMode, sSellerCurASCII, sSellerCurName, sTotalOfferToSeller_SellerCurr, sOfferAmount_SellerCurr, sSellerPremium_SellerCurr, sConditions, sListID,  sDescription, sSKU, sInv_tag, sFasc_loc, sSerialNoandModel, sQTY, iLoopCount, iBidCount, sHTMLConditions, sBidStatus, sBidID, byRef bAlreadyAccepted, sFasc_Address1, sFasc_City, sFasc_State_id, sFasc_Country_id, sFasc_Company_name, sListingCustID, sAskPrice_SellerCurr, sMinPrice_SellerCurr, sListingCur, sOrigLocation)

Стандартная практика, которую я использовал до сих пор, это тратить около часа на чтение приложения, чтобы не только ознакомиться с ним, но и удалить закомментированный / не рекомендуемый код. Тогда работать в глубину моды. Я начну сверху и скопирую сегмент кода в файл aspx.cs и начну переписывать, делая очевидные рефакторинги, особенно когда я использую наши ORM. Если я получу вызов функции, которого у нас нет, я напишу определение.

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

Answer 1

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

Главное, что я запомнил, это:

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

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

Удачи в проекте, больше вопросов, задавайте, пожалуйста:)

Answer 2

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

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

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

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

Answer 3

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

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

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

Удачи!

Answer 4

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

Answer 5

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

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

Answer 6

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

Answer 7

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

Как вы догадались? ;)

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

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

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

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

Answer 8

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

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

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