MVC3 маршрутизация с веб-формами

Question

У меня есть решение, которое использует WebForms .Net 4.0. Я планирую использовать MVC3 в том же решении. Я следовал за Скоттом Хансельманом блогом , и все катилось.

Я должен признать, что я новичок в этом. Тем не менее, кажется, что я упускаю большую часть того, как на самом деле работают маршруты в отношении пространств имен.

В настоящее время наше решение имеет следующее:

WebApplicatin: 
  Accounting
      Receivables
         ReceivablesGrid.aspx
         ReceivableForm.aspx
      Payables
        PayablesGrid.aspx
        PayablesForm
 ..etc.

Таким образом, вы можете запросить страницу, используя

Domain/Accounting/Receivables/ReceivablesGrid.aspx
Domain/Accounting/Receivables/ReceivableForm.aspx?Key=1
Domain/Accounting/Payables/PayablesGrid.aspx
Domain/Accounting/Payables/PayablesForm.aspx?Key=1

....

Я планирую добавить еще один слой, похожий на MVC.

WebApplicatin: 
      Accounting
          Receivables
             ReceivablesGrid.aspx
             ReceivableForm.aspx
             Mobile
              Controllers
                ReceivableConroller.cs
              Models
              Views
                Receivables
                   Index
                   Update
                   Edit
                   Create
          Payables
            PayablesGrid.aspx
            PayablesForm
            Mobile
              Controllers
                PayablesConroller.cs
              Models
              Views
                Payables
                   Index
                   Update
                   Edit
                   Create

     ..etc.

Конечно, это не настоящие имена. Однако я постарался сделать это как можно ближе к моей ситуации. К сожалению, было бы лучше, если бы я следовал этому, потому что я мог бы использовать некоторую логику, которая могла бы быть добавлена ​​в то же пространство имен. Более того, создание папок в корне, похожих на Controllers, Views, Models, не будет работать с моим решением.

В Global.asax я добавил маршрут как таковой:

routes.MapRoute(
      "AccountingReceivablesMobile", // Route name
      "Accounting/Receivables/Mobile/{controller}/{action}/{id}", 
      new { controller = "Home", action = "Index", id = UrlParameter.Optional });

routes.MapRoute(
      "AccountingPayablesMobile", // Route name
      "Accounting/Payables/Mobile/{controller}/{action}/{id}", 
      new { controller = "Home", action = "Index", id = UrlParameter.Optional });

Другое решение, которое я в итоге попробовал, - это расширение RazorViewEngine. В конструкторе нового движка я установил два свойства следующим образом:

base.ViewLocationFormats = new string[] { "~/Accounting/Receivables/Mobile/Views/{1}/{0}.cshtml",
"~/Accounting/Payables/Mobile/Views/{1}/{0}.cshtml"
 };

base.MasterLocationFormats = new[] { "~/Views/Shared/{0}.cshtml"}. 

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

Спасибо

Answer 1

Поскольку ASP.NET MVC (а также Rails и многие другие реализации MVC) полагаются на соглашения по конфигурации , фреймворк действительно хочет иметь \controllers, \views и \models каталоги в корне сайта. Работа, которую вы выполняете, чтобы заставить механизм маршрутизации уловить ваше отклонение от соглашений, - это именно то, что MVC пытается удержать от вас.

Вы могли бы расширить часть фреймворка, например, свои тесты с движком Razor ... Но лично я принимаю соглашения фреймворка, что делает некоторые сценарии, с которыми вы сталкиваетесь, немного сложнее, но я знаю, что другой Разработчик с кратким знанием ASP.NET MVC может открыть код и сразу найти интересующую его область. Если эти папки , основанные на соглашениях , размещать в других папках, это не станет очевидным, если только они не определены как области MVC.

У меня есть два производственных решения, которые представляют собой гибрид ASP.NET WebForms и MVC3. В обоих случаях я использовал стандартный подход (контроллер, модель, просмотр папок в корне) и начал рефакторинг своей устаревшей базы кода веб-форм, чтобы использовать современные стандарты, такие как шаблон репозитория, а также перенести общую бизнес-логику в «службы». пространство имен или новая сборка в решении.

Вернувшись назад, чтобы провести рефакторинг своего кода, чтобы возможно использовать интерфейсы для классов бизнес-логики / репозитория (я предполагаю, что вы этого не делаете, потому что большинство людей не имели веб-форм), вы можете использовать Ninject или другое Контейнер IoC для упрощения подключения этой логики как в устаревших веб-формах, так и в контроллерах MVC, что обеспечивает лучшую структуру и единую проблему; обычно у тебя App_Start().

Что касается выхода за пределы пространства имен, такой инструмент производительности, как ReSharper или CodeRush, автоматически обнаружит и заполнит ваш оператор using, если вы напишите код для другого пространства имен.

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

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

Последнее, что нужно проверить, если ваша основная цель - сделать ваш сайт мобильным, - это эта статья Стива Сандерсона. Он использует превосходную сборку 51Degrees.mobi для обнаружения мобильных устройств и охватывает использование в ASP.NET и ASP.NET MVC. У Сандерсона также есть аналогичная запись в его личном блоге, посвященная той же теме.