Старые варианты миграции сайта - PullRequest
Новая
       21

Старые варианты миграции сайта

0 голосов
/ 04 февраля 2011

У моего клиента есть старый веб-сайт, написанный на Classic ASP, с базой данных MySQL (MyISAM).Это было написано разработчиками с различным уровнем опыта за последние 10 лет.Некоторые аспекты системы - беспорядок.

У него нет CMS, есть корзина покупок и довольно сложные области «Моя учетная запись» и «Администратор».Некоторые из (более простых) областей веб-сайта были преобразованы в ASP.NET (используется MySQL .NET Connector).

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

План такой:

  1. Установите стороннюю o / s CMS (такую ​​как Umbraco), перенесите страницы контента,интегрировать пользовательскую аутентификацию пользователя и связать области «Моя учетная запись» и «Администратор».
  2. Обновление базы данных для поддержки внешних ключей.
  3. Обновление классического сайта ASP и компонентов ASP.NET для поддержки вышеуказанных изменений
  4. Сохраняйте изменения на классическом сайте ASP как минимум и пишите новые вещи в ASP.NET

Итак, вопросы:

  1. Isэто разумный план?Или это будет кусать нас позже?
  2. Какую систему баз данных использовать?MS SQL or MySQL Inno DB?
    • Я лично предпочитаю MS SQL.К счастью, классические ASP были написаны с помощью класса db manager, который обрабатывает все коммуникации, что позволит относительно легко перейти на MS SQL.Но стоит ли усилий?

Ответы [ 2 ]

2 голосов
/ 04 февраля 2011

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

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

0 голосов
/ 23 ноября 2011

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

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

  • Шаг 1 может быть работоспособным, если уровень интеграции между страницами контента и магазином низок.В противном случае вы можете столкнуться с проблемами.Я заметил, что вы уже думали об аутентификации пользователя.Что-нибудь еще подобное?
  • Я полагаю, что шаг 3-4, вероятно, не работает на практике, исключительно из-за моего опыта с плохо разработанным программным обеспечением.Небольшие изменения обычно вызывают цепную реакцию, и вы не сможете их легко изолировать.Ваши шансы на успех зависят от способности делиться и побеждать - под этим я подразумеваю оставление старых частей нетронутыми (кроме аварийных исправлений).По возможности извлекайте решения из внешних источников.
  • Ссылаясь на вышесказанное, замена базовой базы данных может оказаться дорогостоящей.В зависимости от сложности данных и запросов, здесь может быть много скрытых сюрпризов.
  • Это основано на вашем заявлении об ограниченном бюджете.Попытка модифицировать что-то подобное со временем вызывает сомнения, что это будет дешевле, чем полная замена.Это действительно зависит от размера клиента ... если это большой сайт, то полная переработка сложного программного обеспечения займет слишком много времени.Если это небольшой проект, возможно, несколько месяцев для небольшой команды, то я думаю, что будет дешевле сделать все сразу.

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

...