2008-11-11 2 views
2

В настоящее время я работаю над системой управления контентом asp.net-mvc. Было бы невероятно полезно иметь возможность развертывать вложенные приложения, например./магазин, чтобы иметь отдельное приложение внутри. Или еще один экземпляр cms.Вложенные приложения с ASP.NET MVC

Я нашел информацию о том, как ограничить наследование web.config, но я не знаю, как это сопоставляется с приложением MVC. Я надеюсь, что его по существу тот же самый стек он просто запустит. Ничто никогда не бывает таким легким.

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

Si.

ответ

2

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

Первое, что вам понадобится, это HttpModule, который будет вставлен в файл web.config под. Этот модуль будет использоваться для регистрации и пользовательских ViewEngines или Routes, которые вы хотите зарегистрировать. Вы делаете это так же, как в Global.asax, но вместо того, чтобы помещать их в Application_Start, вы помещаете их в статический конструктор HttpModule. Это значит, что они загружаются только как Application_Start.

Сделав это, вы создали модуль, который легко переносится и не требует, чтобы имплицитор модифицировал свой код Global.asax, чтобы заставить ваши вещи работать.

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

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

0

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

  • www.example.com
  • shop.example.com
  • blog.example.com

Это гораздо легче поддерживать, потому что вы можете просто заставить их работать как отдельные веб-сайты в IIS. И, конечно же, вы всегда можете перенаправить www.example.com/shop на shop.example.com.

+0

Это очень плохо для SEO, потому что каждый домен рассматриваются как новый веб-сайт. –

+0

Если ему действительно нужно вложить одно приложение ASP.NET MVC в другое, что может привести к действительно глубоким путям и AFAIK, поисковым системам тоже не понравятся. :) – hangy

+1

На самом деле это неправда. Google изменил свой алгоритм, чтобы рассматривать все поддомены как один и тот же сайт. – Keltex

Смежные вопросы