Выбор: переход с классического ASP на .NET или переход на платформу с открытым исходным кодом.

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

Мы рассмотрели два возможных пути миграции:

1. С нуля переписать как «правильное» приложение ASP.NET, максимально использующее встроенные элементы управления и перенос всех уровней бизнеса и доступа к данным в классы и т. Д. - то есть наш подход к новому проекту ASP.NET.

2. Более простая синтаксическая миграция, при которой страницы ASP переносятся на ASP.NET без внесения слишком большого количества предварительных изменений в структуру или логику. Затем, опираясь на это, мы продолжаем развивать сайт, лучше используя элементы управления ASP.NET, отдельные классы и т. Д. Для новых и пересмотренных функций.

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

Исходя из этого, для первоначальной миграции мы смогли повторно использовать большую часть существующего кода, хотя он постепенно заменяется по мере продвижения вперед. Со «средней» страницей, имеющей, скажем, 50-200 строк HTML и 50-500 строк кода VBScript (как отдельные функции, не смешанные в стиле спагетти HTML), мы обнаружили, что для миграции требуется около часа на страницу. их, включая изменение всего доступа к данным ADO на новый уровень доступа к данным ADO.NET. Некоторые простые страницы занимали всего несколько минут - некоторые из более сложных страниц занимали целый день - но около часа на страницу составляло общее число для сотен страниц, причем время на изменение доступа к данным составляло значительную часть усилий. .

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

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

Вы знаете, что моно существует?

Я думаю, вы обнаружите, что долговечность языка не так важна, как вы думаете, поскольку время жизни основных версий приложения, скорее всего, будет меньше, чем у большинства языков. И, честно говоря, .NET 2.0 -> 3.0 - это довольно небольшой сдвиг вверх, а не упражнение по «выгрузке каждой строчки кода». Если вы даже хотели перейти на более высокую ступень, в этом пока нет необходимости.

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

Выбор зависит от способности вашей компании поддерживать все, что вы выберете.

Собираетесь ли вы сами поддерживать код? Если да, то каков ваш базовый набор навыков прямо сейчас?

Если вы в настоящее время пользуетесь ASP, ASP.NET (переписывание кода или нет) кажется первой идеей, которую стоит попробовать, даже если вы этого не понимаете, используя ASP до сих пор, вы, вероятно, приобрели много знаний в поддержка IIS, а также множества служб и серверов на базе Microsoft, которые вы можете повторно использовать или, по крайней мере, легко адаптировать при разработке, развертывании и поддержке ASP.NET.

ЯВА, РУБИН. Что бы вы ни выбрали, красота / полезность / мощность / удобство использования / долговечность любой технологии лежит на людях, стоящих за ее обслуживанием.

Вам следует задать следующие вопросы:

1. лучше всего направлен на вашу команду
2. кто будет разрабатывать и планировать управление созданным приложением / сервисом?
3. Вы люди Руби? Если нет, ты хочешь им стать?
4. Вы люди JAVA? то же, что и выше
5. ты....?

..и так далее..

Не отвлекайтесь на расходы здесь и там или бесплатные или платные.

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

Это также верно для сред разработки, где вам нужно больше платить за IDE / Server / и т. Д., Но в конечном итоге у вас меньше кривой обучения и поддержки на вашем уровне знаний.

Кроме того: как сказал @annakata, у вас есть много возможностей / проектов для реализации "бесплатных, как в пиве", функциональности ASP.NET .. моно или нет ..

Пример: вы можете настроить службу ASP.NET с помощью Apache, если вам нравятся подобные вещи.

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

Я не думаю, что вам удастся избежать боли, связанной с миграцией каждые 4–5 лет, учитывая, что отрасль постоянно меняется, а инструменты, платформы и языки развиваются для достижения максимальной эффективности. Нет никакой гарантии, что Groovy / Ruby / C # не изменится, чтобы принять следующую важную вещь.

Лично я бы не стал терять сон, пытаясь на 100% подготовиться к будущему. Если это цель, то вы также можете использовать сборку, и даже тогда нет гарантии, что она останется неизменной.

Просто подумайте о следующем: 1) Что знают ваши парни? Если они ребята из vb, имеет смысл перейти на VB.NET 2) Какой у вас бюджет на инструменты? 3) Есть ли на платформе, которую вы хотите переместить, все, что вам нужно? Я помню, как некоторое время назад с изумлением обнаружил поддержку (или ее отсутствие) в Powerbuilder регулярных выражений. 4) Есть ли вокруг платформы сообщество?