Запуск нескольких сайтов из одной базы кода ASP.NET и переход на ASP.NET MVC

Question

У меня достаточно большой проект на работе, который я унаследовал. Это проект веб-сайта ASP.NET 2005 и два проекта библиотеки C # для доступа к данным и немного бизнес-логики. Код на самом деле работает 6 различных веб-сайтов, управляемых базой данных. Он отображает различные изображения и текст для каждого сайта на основе логики, которая проверяет URL-адрес и использует ряд значений Web.config и операторов switch.

Теперь у нас есть несколько новых веб-сайтов, которые будут следовать той же схеме и структуре, что и эти 6, и поэтому руководство решило, что нам не следует изобретать велосипед, и мы должны продолжать расширять существующий код. Несмотря на то, что я понимаю решение с их точки зрения, мысль о расширении этого кода еще большим количеством значений Web.config и еще большим количеством операторов switch во всех отношениях кажется неправильной. Кажется, должен быть лучший способ справиться с этой конкретной формой сложности, но я не знаю, каким должен быть этот лучший способ.

В то же время я искал проект, чтобы начать изучать ASP.NET MVC, и я склонялся к тому, чтобы перестроить этот проект в свое свободное время, поскольку он сложный, но требования код. Я рассчитываю получить 3 вещи от перемещения его в MVC: 1) иметь возможность протестировать приложение и все его версии и все его темные углы, о которых я даже не знаю, 2) надеюсь найти способ сделать управление около 12 сайтами на единой управляемой базе кода и 3) изучение MVC.

Немного побродив, вот некоторые конкретные вопросы:

Будет ли MVC действительно предлагать мне более эффективные способы управления проблемой 12 сайтов в 1 кодовой базе? Мне сложно сказать, не имея глубоких знаний о MVC.

Существует ли шаблонный шаблон или структура, которые я могу применить (в WebForms или MVC), которые подходят для сайтов, подобных этим, которые имеют похожее содержание и структуру и работают из одной и той же базы кода?

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

Спасибо за время. Я ценю это!

Answer 1

Будет ли MVC действительно предлагать мне более эффективные способы управления 12-ю площадками в одном выпуске кода?

Честно говоря: я бы не пошел по этому пути. ASP.NET достаточно мощный, чтобы иметь многопользовательскую систему. Есть вещи, которые помогают создавать многопользовательские приложения в ASP.NET MVC. У вас есть IoC для изменения бизнес-правил между приложениями, и у вас есть возможность динамически выбирать, какое представление отображать. У вас есть тестабильность.

Вот и все замечательно: читайте здесь об этом ссылка так

Но, тем не менее: это огромная попытка внедрить такую ​​систему. ASP.NET великолепен (теперь у вас есть Routing!), И если у вас есть работающая система, лучше потратьте время на ее улучшение.

Answer 2

ASP.Net MVC может иметь некоторые реальные преимущества для вас здесь. Вы не будете больше вручную проверять URL-адреса, потому что функциональность MVC маршрутизации сделает это за вас - так что, в некотором смысле, это «лучший способ». Вот некоторые преимущества:

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

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

3. Частичное представление было бы отличным способом для переключения содержимого, специфичного для сайта, в угловых случаях, когда шаблон не был одинаковым для каждого сайта.

Пока логика была достаточно схожей для каждого сайта, ASP.Net MVC 1.0 мог справиться с этим. Если вам нужна разная логика контроллера для каждого сайта, в следующем выпуске ASP.Net MVC есть концепция «областей», которая позволит вам реализовать разные сайты в одном приложении, у всех из которых есть свои собственные каталоги Controller, Model и View - но были дифференцированы по их маршрутам.