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

Question

В моей организации много устаревшего программного обеспечения ASP.

Поскольку мы считаем, что Microsoft продемонстрировала явную нехватку поддержки для своих старых продуктов, нам необходимо выяснить, что перейти на следующую.

Если мы перейдем на ASP.NET из классического ASP, создается впечатление, что это будет «полная перезапись» «миграции». Поскольку это, вероятно, так, мы думаем о переходе на бесплатную (как в пиве, так и в речи) платформу. Я особенно думаю, что наши инвестиции (я имею в виду усилия по программированию) были бы лучше потрачены на платформу, которая позволит нам развиваться, а не заставлять нас бросать одну строчку кода каждые 4/5 лет. Это основной аргумент, который мы использовали для продвижения к «свободной» платформе.

В настоящее время мы думаем об использовании смеси Java с динамическим языком, таким как JRuby или Groovy.

Мои вопросы: что было бы хорошим выбором для миграции? Наши страхи необоснованны? Должны ли мы (предположительно) переписать большую часть кодовой базы через 4 или 5 лет? Какие у вас есть аргументы для перехода на .NET или на бесплатную платформу?

Answer 1

Недавно мы перенесли существенный проект 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, которая затем позволяет вам опираться на эту основу, максимально используя имеющуюся кодовую базу и навыки.

Answer 2

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

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

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

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

Вопросы, которые вы должны задать:

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

.. и т. Д. *

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

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

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

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

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

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

Answer 3

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

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

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

Answer 4

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

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

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