Классический ASP и MVC рядом, разные проекты? - PullRequest
Новая
       21

Классический ASP и MVC рядом, разные проекты?

4 голосов
/ 06 мая 2010

Я пытался задать это несколькими разными способами, но давайте попробуем еще раз (так как я еще не получил ответ, и это сводит меня с ума!)

У меня есть очень большое классическое приложение ASP 3.0 (~ 350 тыс. Строк), которое я хочу начать мигрировать в ASP.NET MVC. Я хотел бы сохранить старые файлы ASP в отдельном проекте от материала MVC.

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

Ответы [ 2 ]

4 голосов
/ 12 мая 2010

После долгих исследований я обнаружил, что хорошим способом объединения этих проектов с точки зрения IIS, но в отдельных проектах в Visual Studio, является создание проектов в одной папке, но при этом файлы для каждого в своих .csproj файлах.

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

Пока это работает довольно хорошо. Единственным другим изменением было добавление правила игнорирования маршрута в файл global.asx.cs для игнорирования файлов .asp: 

             routes.IgnoreRoute("{resource}.asp/{*pathInfo}");

Пока что все работает довольно хорошо.

3 голосов
/ 07 мая 2010

Отказ от ответственности это не в моей голове, я никогда не делал этого и мог быть далеко от цели:

После первоначального рассмотрения, я думаю, у вас есть 3 альтернативы, обсуждаемые ниже:

  1. Слияние в одно приложение,
  2. Иметь одно приложение в качестве корневого приложения, а другое - в качестве «вспомогательного» приложения
  3. Копировать слияние в одно приложение после сборки (это может быть невозможно)

1) Объединение в 1 приложение дает вам следующие преимущества, относительно просто вам необходимо изменить global.asax - настроить маршруты mvc, IOC и т. Д. - HttpApplication, Session and Security (предположим, что на основе форм) ) будет просто работать.

Существует одна несколько «второстепенная» проблема, связанная с совместным использованием tempData, которую вы сможете создать, если сможете создать экземпляр SessionStateTempDataProvider на своей странице (инициализировать загрузку, выгрузить, сохранить аналогично состоянию просмотра), я не могу показаться чтобы найти блог, но думаю, что это был Стив Сандерсон несколько месяцев назад.

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

2) С помощью этой опции вы получите полное разделение приложений с новым наследственным набором проблем. HttpApplication. * Может вызвать проблему, если ваши приложения используют его, потому что они будут ссылаться на разные папки, контексты и т. Д., Но игнорируя утверждение о том, что вы довольны тем, что это разные приложения

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

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

3) Предполагая, что вы берете свой сайт asp.net и добавляете ссылку на mvc и добавляете в глобальную маршрутизацию asax по умолчанию и т. Д., Приложение все равно должно собираться чисто, но выдает ошибки маршрутизации при поиске / маршруты типа контроллера / действия / идентификатора, поэтому вам может потребоваться проверить это.

Предполагая, что это работает, вы можете «потенциально» выполнить слияние xcopy двух приложений (то есть скопировать все файлы из приложения mvc в предварительное развертывание приложения asp.net). Я знаю, что вы можете сделать это, создав один большой проект, в котором оба приложения уже объединены, но таким образом код объединяется на более позднем этапе процесса сборки. (Подписанные собрания, приходят на ум как хлопотно). И снова вам нужно будет работать над проблемой временных данных ...

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

Подводя итог, я думаю, что ваши самые большие проблемы будут HttpApplication, Session и TempData со стороны mvc, просмотр состояния со стороны asp.net. Переписывание URL, аутентификация должна быть проще.

И как сказал Форрест Гамп: «Это мои мысли об этом».

...