2011-12-15 2 views
0

Мне нужно создать приложение ASP.NET MVC 3, которое может перенаправить на другие приложения ASP.NET MVC 3, вызвав их контроллер/действие. Я думал просто создать URL. Мне нужно было бы знать имена контроллеров/действий и хост. Я думал о хранении строк хоста в базе данных, поэтому, если приложение будет перемещено, я смогу обновить базу данных с помощью этой информации без внесения изменений в код и перекомпиляции. Я просто не уверен, что это лучший подход. Любая помощь будет действительно оценена.Перенаправление на другой контроллер/действие в приложении forther

ответ

0

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

+0

Спасибо Адаму за ваш ответ. Посмотрев, как они настроили свой виртуальный каталог IIS, я вижу, что приложение, над которым я работаю, является родителем, а все остальные приложения - это приложения. Любой контроллер в главном приложении будет знать, что такое приложение/контроллер/действие для вызова, поэтому я думал, что все, что мне нужно сделать, это переадресовать («имя_пользователя/имя_контроллера/имя_пользователя») и добавить к нему любые запросы. Правильно ли это звучит? – Cam

+0

ya. Если он всегда является подкаталогом, вы можете получить текущий URL-адрес приложения, используя «~» в начале и добавить в подпапки под ним. Несколько способов сделать это здесь, но по существу, вы имеете это правильно. Я предполагаю, что эти uris все хранятся где-то, хотя для облегчения будущих изменений:) –

+0

Я думал об этом, но поскольку каждый контроллер узнает, что приложение для вызова, я не знал, было ли это заложено, запустив web.config или базу данных. – Cam

1

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

Сравнивая его с SQL-запросом - SQL-запрос обычно описывает только то, что вы хотите, а не как вы хотите, чтобы сервер базы данных извлекал то, что вы хотите.

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