Переход от 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 .СЕТЬ! : S (да, я боюсь!).

Основные вещи, которые я сохранивших на мой взгляд, это:

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

Ее очень нравится играть Jenga с кодом :)

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

Answer 2

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

Answer 3

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

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

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

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

Answer 4

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

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

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

Answer 5

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

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

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

Удачи вам!

Answer 6

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

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

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

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

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

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

Answer 7

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

Answer 8

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

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