Структура двух разных сайтов, где внешние страницы разные, внутренние страницы одинаковы

Question

У меня есть сайт ASP.Net MVC, «изучающий мандарин онлайн». Он работает, и он отлично работает для меня. Теперь я хочу повторно использовать этот веб-сайт в качестве шаблона для нового веб-сайта, «изучая испанский онлайн». Оба веб-сайта будут находиться на совершенно разных доменах и на совершенно разных серверах.

Для моего «обучения мандарина онлайн» веб-сайт, 1/3 из веб-страниц являются внешние страницы, которые пользователь может просматривать без регистрации на сайте. Другие 2/3 веб-страниц внутренние страниц, что пользователь может видеть только ли они на сайте. Я хочу оба веб-сайта для использования разных внешних страниц (внешние страницы .aspx будут отличаться для обоих сайтов), но оба сайта используют один и тот же набор внутренних страниц (внутренние страницы .aspx будут одинаковыми для обоих сайтов).

Вопрос в ASP.Net MVC, как я могу структурировать проект/решение для обоих сайтов? Поскольку единственное различие для обоих веб-сайтов - это внешние страницы, самым простым решением, которое я могу придумать для обработки внешних страниц, является сохранение отображений для каждого представления в базе данных, извлечение этого сопоставления из базы данных на основе некоторой константы (например, WebsiteType) установить в web.config, а затем вернуть представление, основанное на сопоставлении. Например, в моем контроллере:

// WebsiteType is stored in web.config. It is set to LearnMandarin for the learn Manadarin 
// online website and it is set to LearnSpanish for the learn Spanish online website 
string websiteType = WebConfigurationManager.AppSettings["WebsiteType"]; 

// figure out which Homepage .aspx view to return, based on the websiteType 
// GetView(...) will get the mapping from the database 
string viewToReturn = GetView(websiteType, "HomepageView"); 

return View(viewToReturn); 

Это чистое решение я могу думать так далеко и лучшая структура я могу думать. Я бы в итоге имел два разных файла .aspx в одном каталоге - одну .aspx страницу для изучения онлайн-сайта Mandarin, файл another.aspx для изучения испанского онлайн-сайта. Является ли это лучшим способом структурирования моего проекта или есть еще более чистый способ?

(Я использую Visual Studio 2010 и ASP.Net MVC версии 3.0.0.0)

Answer 1

Я более или менее использовал районы, как предложил Хейни. В моем проекте я создал область под названием SpanishTutor. Как только вы создадите область, она будет иметь тот же контроллер и структуру папок представления, что и обычный ASP.Net MVC-проект (но все они будут находиться под папкой «Области»). Я считаю мою домашнюю страницу одной из моих «внешних» страниц. Таким образом, я создаю файл HomeController.cs в папке «controller» в моей области SpanishTutor. Для этого файла HomeControllers.cs мне пришлось изменить пространство имен на «Tutors.Areas.SpanishTutor.Controllers», чтобы он не противоречил существующему файлу HomeController.cs. Я также создаю домашнюю папку с Index.aspx под папкой «views» в моей области SpanishTutor.

Далее мне нужно было зарегистрировать маршрутизацию для моей домашней страницы «learn Spanish online», чтобы переопределить маршрутизацию моей домашней страницы «learn Mandarin online». Когда вы создаете область SpanishTutor, создается файл .cs, называемый SpanishTutorAreaRegistration.cs. В этом файле, добавьте следующий код в RegisterArea (...):

public override void RegisterArea(AreaRegistrationContext context) 
{ 

    string websiteType = WebConfigurationManager.AppSettings["WebsiteType"]; 

    if (websiteType.Contains("spanishtutor")) 
    { 
    context.MapRoute(
     "SpanishTutor_Root", // Route name 
     "", // override the homepage 
     new { controller = "Home", action = "Index", id = UrlParameter.Optional }, // Parameter defaults 
     new[] { "Tutors.Areas.SpanishTutor.Controllers" } // namespace so there is no conflict with the namespace of the original homeapge 
    ); 
    } 
} 

Если у вас есть несколько внешних веб-страниц, вы можете добавить каждую внешний веб-страницу так же, как домашняя страница. Для меня не было необходимости изменять Global.asax.cs.

В моей web.config добавьте следующее (я могу изменить его на «mandarintutor» на сайте «узнать мандарин онлайн»):

<add key="WebsiteType" value="spanishtutor" /> 

Answer 2

Ну, я бы согласился с @Haney, до такой степени. Это действительно зависит от того, насколько отличаются мандаринские/испанские защищенные разделы сайта. В общем, разделение между защищенными и незащищенными секциями прост. Контроллеры/Действия, доступные только для зарегистрированных пользователей, должны быть защищены атрибутом [Authorize]. Чтобы сделать что-то вроде ограничения пользователя, который только подписался на мандарин в раздел Мандарин, например, вы будете использовать роли. Например, назначьте пользователю роль «мандарин», а затем укажите, что к ней могут обращаться только пользователи этой роли: [Authorize(Roles = "Mandarin")].

Куда он начинает получать больше, если есть разница между мандаринским и испанским разделами. Для большинства вещей вы могли бы сделать язык параметром маршрута. Другими словами, все страницы мандарина будут иметь URL-адрес, такой как /mandarin/some/page/, а на испанских страницах - URL-адрес /spanish/some/page/. Вы можете использовать параметр маршрута, затем, чтобы отключить макеты, разветвить внутри действия или просмотреть и т. Д. Однако, если между этими двумя разделами существует большая разница, все это ветвление может привести к некоторому сложному коду. Если это будет так, тогда было бы более целесообразно создать каждый язык как отдельную область. Каждая область получит отдельную схему маршрутизации, т. Е. Если ваша область имеет имя Mandarin, то каждое действие контроллера в этой области будет автоматически находиться под URL-адресом, например /mandarin/some/page/. Вам не нужно было бы захватить часть мандарина для определения языка в игре: просто, нажав на действие контроллера в этой области, вы бы знали. Однако недостатком этого подхода является то, что вы можете в итоге дублировать код. Вы можете предотвратить большую часть этого с помощью контроллера и просмотреть наследование, но могут возникнуть ситуации, когда вы по-прежнему заканчиваете очень похожий код, существующий в обеих областях.