что такое mvc asp net
Общие сведения об ASP.NET MVC
Узнайте о различиях между приложением mVC ASP.NET и приложениями ASP.NET Web Forms. Узнайте, как решить, когда создавать ASP.NET приложение MVC.
Схема архитектуры Model-View-Controller (MVC) разделяет приложение на три основных компонента: модель, представление и контроллер. Платформа ASP.NET MVC является альтернативой шаблону ASP.NET Web Forms для создания веб-приложений на основе MVC. Платформа ASP.NET MVC является легковесной платформой отображения с широкими возможностями тестирования и, подобно приложениям на основе веб-форм, интегрирована с существующими функциями ASP.NET, например с главными страницами и проверкой подлинности на основе членства. Платформа MVC определена в пространстве имен System.Web.Mvc и является фундаментальной, поддерживаемой частью пространства имен System.Web.
MVC представляет собой стандартный шаблон разработки, знакомый многим специалистам. Некоторые типы веб-приложений имеют преимущества при создании на платформе MVC. Для других может быть целесообразно использование традиционной схемы приложения ASP.NET, основанной на веб-формах и обратной передаче. В некоторых случаях возможно сочетание двух подходов: применение одной схемы не исключает использования другой.
В состав платформы MVC входят следующие компоненты.
Рисунок 01: Ссылка на действие контроллера, которое ожидает значение параметра(Нажмите, чтобы просмотреть полноразмерное изображение)
В небольших приложениях эта модель подразумевает концептуальное, а не физическое разделение. Например, если приложение читает только набор данных и отправляет его в представление, приложение не имеет физического слоя модели и связанных классов. В этом случае набор данных берет на себя роль объекта модели.
Просмотры. Представления — это компоненты, отображающие пользовательский интерфейс приложения (UI). Пользовательский интерфейс обычно создается на основе данных модели. Примером может быть редактирование представления таблицы Продуктов, отображающая текстовые ящики, списки выпадающих и чековых коробок в зависимости от текущего состояния объекта продуктов.
Контроллеры. Контроллеры осуществляют взаимодействие с пользователем, работу с моделью, а также выбор представления, отображающего пользовательский интерфейс. В приложении MVC представление служит только для отображения информации. Обработку введенных данных, формирование ответа и взаимодействие с пользователем обеспечивает контроллер. Например, контроллер обрабатывает значения строки запроса и передает эти значения модели, что, в свою очередь, запрашивает базу данных с помощью значений.
Шаблон MVC позволяет создавать приложения, различные аспекты которых (логика ввода, бизнес-логика и логика интерфейса) разделены, но достаточно тесно взаимодействуют друг с другом. Эта схема указывает расположение каждого вида логики в приложении. Логика пользовательского интерфейса относится к представлению. Логика ввода относится к контроллеру. Бизнес-логика размещается в модели. Это разделение позволяет работать со сложными структурами при создании приложения, так как обеспечивает одновременную реализацию только одного аспекта. Например, разработчик может сконцентрироваться на создании представления отдельно от бизнес-логики.
В дополнение к упрощению сложных структур схема MVC также облегчает тестирование приложений по сравнению с веб-приложениями ASP.NET на основе веб-форм. Например, в веб-приложении ASP.NET на основе веб-форм один класс используется для отображения вывода и для ответа на ввод пользователя. Создание автоматических тестов для приложений ASP.NET на основе веб-форм может представлять сложности, так как для тестирования отдельной страницы следует создать экземпляр класса страницы, всех дочерних элементов управления и других зависимых классов приложения. Большое число экземпляров классов, необходимое для запуска страницы, усложняет создание тестов для отдельных частей приложения. Из-за этого тестирование приложений ASP.NET на основе веб-форм может быть сложнее тестирования приложения MVC. Более того, для тестирования приложения ASP.NET необходим веб-сервер. Платформа MVC разделяет компоненты и активно использует интерфейсы, что позволяет тестировать отдельные элементы вне остальной структуры.
Связь между основными компонентами приложения MVC также облегчает параллельную разработку. Например, один разработчик может работать над представлением, второй разработчик может работать над логикой контроллера, а третий — на бизнес-логике в модели.
Решение о создании приложения MVC
Следует внимательно продумать вопрос о создании веб-приложения на основе платформы ASP.NET MVC или на основе модели веб-форм ASP.NET. Платформа MVC не заменяет собой модель веб-форм. Обе модели можно использовать для веб-приложений. (при наличии существующих приложений на основе веб-форм они будут продолжать работу в нормальном режиме).
Перед использованием платформы MVC или модели веб-форм для определенного веб-сайта следует взвесить все преимущества каждого из подходов.
Преимущества веб-приложения на основе MVC
Платформа ASP.NET MVC имеет следующие преимущества.
Преимущества веб-приложения на основе веб-форм
Платформа на основе веб-форм имеет следующие преимущества.
Начало работы с MVC ASP.NET Core
Автор: Рик Андерсон (Rick Anderson)
В этом руководстве описывается веб-разработка MVC ASP.NET Core с контроллерами и представлениями. Если вы не знакомы с веб-разработкой ASP.NET Core, для начала изучите версию этого руководства для Razor Pages. См. раздел Выбор пользовательского интерфейса ASP.NET Core, где сравниваются Razor Pages, MVC и Blazor для разработки пользовательского интерфейса.
Это первое руководство из серии материалов по веб-разработке MVC ASP.NET Core с использованием контроллеров и представлений.
Пройдя всю серию, вы создадите приложение, которое управляет базой данных фильмов и отображает ее. Вы научитесь:
Предварительные требования
Создание веб-приложения
Альтернативные подходы к созданию проекта см. в статье Создание проекта в Visual Studio.
В Visual Studio используется шаблон проекта по умолчанию для созданного проекта MVC. Созданный проект это:
В этом руководстве предполагается, что вы умеете работать с VS Code. Дополнительные сведения см. в разделах Начало работы с VS Code и Справка по Visual Studio Code.
Выполните следующую команду:
Появится диалоговое окно с предупреждением В MvcMovie отсутствуют необходимые ресурсы для сборки и отладки. Добавить их? Выберите Да.
Запуск приложения
Нажмите клавиши CTRL+F5, чтобы запустить приложение без отладчика.
Visual Studio отображает следующее диалоговое окно, если проект еще не настроен для использования SSL:
Выберите Да, чтобы сделать SSL-сертификат IIS Express доверенным.
Отобразится следующее диалоговое окно.
Выберите Да, если согласны доверять сертификату разработки.
Visual Studio запускает приложение и открывает браузер по умолчанию.
Запуск приложения без отладки путем нажатия клавиш CTRL+F5 позволяет:
Из меню Отладка можно запустить приложение с отладкой или без:
Вы можете выполнить отладку приложения, нажав кнопку MvcMovie на панели инструментов:
Пример приложения приведен на следующем рисунке:
Нажмите клавиши CTRL+F5 чтобы выполнить запуск без отладчика.
Настройте доверие сертификату разработки HTTPS с помощью следующей команды:
Предыдущая команда не работает в Linux. Сведения о настройке доверия к сертификату см. в документации по вашему дистрибутиву Linux.
Приведенная выше команда отображает следующее диалоговое окно, если сертификат не был ранее доверенным:
Выберите Да, если согласны доверять сертификату разработки.
Visual Studio Code:
Запуск приложения без отладки путем нажатия клавиш CTRL+F5 позволяет:
Внесите изменения в код.
Быстро обновить браузер и просмотреть изменения в коде.
Выберите Выполнить > Запуск без отладки, чтобы запустить приложение.
Visual Studio для Mac:
В Visual Studio для Mac отображается следующее всплывающее окно:
Выберите Да, если вы доверяете сертификату разработки.
Отобразится следующее диалоговое окно.
Введите пароль и нажмите кнопку ОК.
Выберите Да, если согласны доверять сертификату разработки.
В меню Запуск можно запустить приложение в режиме с отладкой или без нее.
Пример приложения приведен на следующем рисунке:
Общие сведения ASP.NET Core MVC
Автор: Стив Смит (Steve Smith)
ASP.NET MVC является многофункциональной платформой для создания веб-приложений и API-интерфейсов с помощью структуры проектирования Model-View-Controller.
Шаблон MVC
Структура архитектуры MVC разделяет приложение на три основных группы компонентов: модели, представлении и контроллеры. Это позволяет реализовать принципы разделения задач. Согласно этой структуре запросы пользователей направляются в контроллер, который отвечает за работу с моделью для выполнения действий пользователей и (или) получение результатов запросов. Контроллер выбирает представление для отображения пользователю со всеми необходимыми данными модели.
На следующей схеме показаны три основных компонента и существующие между ними связи.
Такое распределение обязанностей позволяет масштабировать приложение в контексте сложности, так как проще писать код, выполнять отладку и тестирование компонента (модели, представления или контроллера) с одним заданием. Гораздо труднее обновлять, тестировать и отлаживать код, зависимости которого находятся в двух или трех этих областях. Например, логика пользовательского интерфейса, как правило, подвергается изменениям чаще, чем бизнес-логика. Если код представления и бизнес-логика объединены в один объект, содержащий бизнес-логику, объект необходимо изменять при каждом обновлении пользовательского интерфейса. Это часто приводит к возникновению ошибок и необходимости повторно тестировать бизнес-логику после каждого незначительного изменения пользовательского интерфейса.
Представление и контроллер зависят от модели. Однако сама модель не зависит ни от контроллера, ни от представления. Это является одним из ключевых преимуществ разделения. Такое разделение позволяет создавать и тестировать модели независимо от их визуального представления.
Функции модели
Модель в приложении MVC представляет состояние приложения и бизнес-логику или операций, которые должны в нем выполняться. Бизнес-логика должна быть включена в состав модели вместе с логикой реализации для сохранения состояния приложения. Как правило, строго типизированные представления используют типы ViewModel, предназначенные для хранения данных, отображаемых в этом представлении. Контроллер создает и заполняет эти экземпляры ViewModel из модели.
Функции представления
Функции контроллера
Контроллеры — это компоненты для управления взаимодействием с пользователем, работы с моделью и выбора представления для отображения. В приложении MVC представление служит только для отображения информации. Обработку введенных данных, формирование ответа и взаимодействие с пользователем обеспечивает контроллер. В структуре MVC контроллер является начальной отправной точкой и отвечает за выбор рабочих типов моделей и отображаемых представлений (именно этим объясняется его название — он контролирует, каким образом приложение отвечает на конкретный запрос).
Контроллеры не должны быть чересчур сложными из-за слишком большого количества обязанностей. Чтобы не перегружать логику контроллера, перенесите бизнес-логику из контроллера в модель предметной области.
Если ваш контроллер часто выполняет одни и те же виды действий, переместите эти действия в фильтры.
ASP.NET Core MVC
ASP.NET Core MVC представляет собой упрощенную, эффективно тестируемую платформу с открытым исходным кодом, оптимизированную для использования с ASP.NET Core.
ASP.NET Core MVC предоставляет основанный на шаблонах способ создания динамических веб-сайтов с четким разделением задач. Она обеспечивает полный контроль разметки, поддерживает согласованную с TDD разработку и использует новейшие веб-стандарты.
Маршрутизация
Платформа ASP.NET Core MVC создана на основе маршрутизации ASP.NET Core — мощного компонента сопоставления URL-адресов, который позволяет создавать приложения с понятными и поддерживающими поиск URL-адресами. Вы можете определять шаблоны именования URL-адресов приложения, эффективно работающие для оптимизации для поисковых систем (SEO) и для создания ссылок, независимо от способа организации файлов на веб-сервере. Вы можете определять маршруты с помощью понятного синтаксиса шаблонов маршрутов, который поддерживает ограничения значений маршрутов, значения по умолчанию и необязательные значения.
Маршрутизация на основе соглашений позволяет глобально определять форматы URL-адресов, которые принимает приложение, и то, как каждый из этих форматов соответствует конкретному методу действия на данном контроллере. При поступлении входящего запроса модуль маршрутизации выполняет синтаксический анализ URL-адреса и соотносит его с одним из определенных форматов URL-адресов, а затем вызывает метод действия связанного контроллера.
Маршрутизация атрибутов используется для указания сведений о маршрутизации путем добавления атрибутов, определяющих маршруты приложения, к контроллерам и действиям. Это означает, что определения маршрутов помещаются рядом с контроллером и действием, с которым они связаны.
Привязка модели
Привязка модели в ASP.NET Core MVC преобразует данные запроса клиента (значения форм, данные маршрута, параметры строки запроса, заголовки HTTP) в объекты, которые может обрабатывать контроллер. В результате логике контроллера не требуется определять данные входящего запроса — данные просто доступны в виде параметров для методов действий.
Проверка модели
ASP.NET MVC поддерживает возможность проверки, дополняя модель объекта атрибутами проверки заметок к данным. Атрибуты проверки проверяются на стороне клиента до размещения значений на сервере, а также на сервере перед выполнением действия контроллера.
Платформа обрабатывает проверку данных запроса на клиенте и на сервере. Логика проверки, указанная в типах модели, добавляется в готовые для просмотра представления в виде ненавязчивых заметок и реализуется в браузере с помощью подключаемого модуля jQuery Validation.
Внедрение зависимостей
ASP.NET Core имеет встроенную поддержку внедрения зависимостей (DI). В ASP.NET MVC Core контроллеры могут запрашивать необходимые служб через свои конструкторы, предоставляя им возможность следовать принципу явных зависимостей.
Кроме того, приложение может использовать внедрение зависимостей в файлы представления с помощью директивы @inject :
Фильтры
Фильтры помогают разработчикам решать общие задачи, такие как обработка исключений или авторизация. Фильтры активируют пользовательскую логику предварительной и завершающей обработки для методов действий и могут быть настроены для запуска в определенные моменты в конвейерном выполнении определенного запроса. Фильтры могут применяться к контроллерам или действиям в виде атрибутов (или могут выполняться глобально). В состав платформы входит несколько фильтров (например, Authorize ). [Authorize] является атрибутом, который используется для создания фильтров авторизации MVC.
Области
области позволяют секционировать крупные ASP.NET Core веб-приложения MVC в более мелкие функциональные группы. Область является структурой MVC внутри приложения. В проекте MVC логические компоненты, такие как модель, контроллер и представление, находятся в разных папках, и для создания связи между этими компонентами MVC использует соглашения об именовании. Крупное приложение может быть целесообразно разделить на отдельные высокоуровневые области функциональности. Например, приложение электронной коммерции с несколькими подразделениями, например извлечение, выставление счетов и поиск и т. д. Каждое из этих устройств имеет собственные представления логических компонентов, контроллеры и модели.
Веб-API
Помимо того, что ASP.NET Core MV прекрасно подходит для создания веб-сайтов, эта платформа располагает мощной поддержкой для построения веб-API. Создавайте службы, доступные для широкого круга клиентов, включая браузеры и мобильные устройства.
Платформа поддерживает согласования содержимого HTTP со встроенной поддержкой для форматирования данных в виде JSON или XML. Пишите пользовательские модули форматирования для добавления поддержки собственных форматов.
Используйте функции создания ссылок для поддержки гипермедиа. Легко включайте поддержку общего доступа к ресурсам независимо от источника (CORS) для совместного использования веб-API в нескольких веб-приложениях.
Тестирование
Благодаря используемым интерфейсам и внедрению зависимостей платформа хорошо подходит для модульного тестирования. Кроме того, с помощью таких компонентов, как TestHost и поставщик InMemory для Entity Framework, можно быстро и просто выполнять интеграционные тесты. Узнайте больше о тестировании логики контроллеров.
Razor Просмотреть подсистему
ASP.NET Core представления MVC используют Razor обработчик представлений для отображения представлений. Razor — Это компактный, выразительный и жидкий язык разметки шаблонов для определения представлений с помощью встраиваемого кода C#. Razor используется для динамического создания веб-содержимого на сервере. Серверный код можно полностью комбинировать с содержимым и кодом на стороне клиента.
С помощью Razor обработчика представлений можно определять макеты, частичные представления и заменяемые разделы.
Строго типизированные представления
Razor представления в MVC могут быть строго типизированы на основе модели. Контроллеры передают строго типизированную модель в представления для поддержки в них IntelliSense и проверки типов.
Например, следующее представление отображает модель типа IEnumerable
Вспомогательные функции тегов
Вспомогательные функции тегов позволяют коду на стороне сервера принимать участие в создании и ОТРИСОВКЕ HTML-элементов в Razor файлах. Вспомогательные функции тегов используются для определения настраиваемых тегов (например, ) или для изменения поведения существующих тегов (например, ). Вспомогательные функции тегов привязываются к определенным элементам на основе имени элемента и его атрибутов. Они предоставляют преимущества отрисовки на стороне сервера, сохраняя при этом возможности редактирования HTML.
Существует множество встроенных вспомогательных функций тегов для общих задач — например, для создания форм, ссылок, загрузки ресурсов и т. д. Кроме того, огромное количество функций доступно в общедоступных репозиториях GitHub и в качестве пакетов NuGet. Вспомогательные функции тегов разрабатываются на C# и предназначены для HTML-элементов на основе имени элемента, имени атрибута или родительского тега. Например, встроенную функцию LinkTagHelper можно использовать для создания ссылки на действие AccountsController для Login :
С помощью EnvironmentTagHelper можно включать в приложения различные сценарии (например, необработанные или минифицированные) для конкретной среды выполнения (разработки, промежуточной или производственной):
Вспомогательные функции тегов обеспечивают удобный для HTML процесс разработки и расширенную среду IntelliSense для создания HTML и Razor разметки. Большинство встроенных вспомогательных функций тегов работают с существующими HTML-элементами и предоставляют для них атрибуты на стороне сервера.
Компоненты представлений
Компоненты представлений позволяют упаковывать логику отрисовки и повторно использовать ее в приложении. Они аналогичны частичным представлениям, но имеют связанную логику.
ASP.NET MVC на реальном примере. Теория и вступление.
Команда Microsoft очень интенсивно развивает свои продукты и средства для разработчиков. На эту тему уже и выхлопы шуточные были, по поводу выхода новых версий фреймворков. Разработчики, которые работают в крупных компаниях, ввязаны в большие проекты в общем-то без особого энтузиазма на это смотрят, так как такие махины нельзя в короткие сроки перевести на новую версию. Может быть чревато как всплыванием багов, так и изменением всей структуры проекта, что делать не всегда получается легко. Сказанное выше, к сожалению (или к счастью), меня не касается и это дает мне возможность использовать все самое новое без оглядки на бекграунд. Проекты довольно таки обозримые, часто переводятся на новую версию безболезненно, и новые фичи начинаю внедрять уже при реализации следующей задачи в пректе. На момент внедрения это, конечно, вносит некий хаос в код, так как в разных кусках кода используются разные принципы (например, внедрение LINQ), но последующий рефакторинг кода приводит все к единому виду и все приходит в норму.
К чему все это?
Принцип работы MVC
Что нам это дает полезного? Мы получаем полный контроль над выводимым HTML. Более «легкие» приложения. Приверженцы TDD (Test-Driven Development) будут в восторге, MVC позволяет этим подходом пользоваться на полную катушку и тестировать практически все. Ещё мы получаем полное разделение логики от представления данных. Кто-то просто скажет «ну наконец-то все для людей», а кого-то это будет дисциплинировать, чтобы не писали в обработчике нажатия на кнопку код для работы с данными. К стати я упомянул обработчики? Забудьте. Этого больше нет. Нет обработчиков событий, нет ViewState, нет Drag’n’Drop контролов на форму. Да, руками прийдется больше хардкодить, кому-то может даже подучить и узнать как это все на самом деле работает. В тоже время если мы лишились фич, которые просто противоречат идее MVC, мы не лишились основного. В нашем распоряжении остались MasterPages, UserControls, Membership. В общем все не так уж плохо, как может показаться на первый взгляд. Пришел ли MVC на смену WebForms? Нет, WebForms будут так же жить и развиваться. MVC просто дает возможность писать приложения по другому. Если у вас есть приложение по работе с кучей данных, редактировании в GridView и т.д., то для вас WebForms и останутся правильным решением. Ещё с MVC вы забудете о всех проблемах с URL-Rewriting, возможно это и не настолько проблема в WebForms, конечно, но для MVC — это родная фича.
От теории к практике?
На днях попался мне проект от хорошего знакомого. Нужен новый сайт для сервисного центра портативной электроники. Старый есть, но немного неустраивает. По сути ничего сложного: пяток информационных страниц, каталог доступных аксессуаров с ценами и интеграция с 1C. Ради последнего и поднялся вопрос. Вся база ведется на 1С, хочется, чтобы клиент мог, зайдя на сайт и введя номер своей квитанции, увидеть состояние ремонта: готов не готов, все ли отремонтировали по гарантии или за что-то прийдется доплатить.
Подготовка к работе
Далее нам предложит создать Unit Test Project для нашего приложения, пока обойдемся без него.
В итоге мы получили наш чистенький проект вот в таком виде:
Наряду с уже привычными директориями появились и незнакомые нам. Пройдемся по порядку:
/Properties — стандартная директория для Web Application, содержит настройки проекта.
/References — ссылки на другие сборки, проекты и т.д.
/App_Data — специальная директория для хранения данных
/Content — в этой директории мы будем хранить изображения, стили и ему подобное. В общем-то, весь статический контент сайта
/Controllers — классы, отвечающие за компоненты Controller
/Models — классы с нашей логикой
/Views — непосредственно UI нашего приложения. В этой директории создаются директории для каждого контроллера (/Views/Home в нашем случае). И уже в них по aspx странице для каждого из методов котроллера.
/View/Shared — содержит то, что нам может пригодиться для всех контроллеров, например MasterPages и UserControls.
Чтоже, попробуем запустить? Вуаля! Получили результат:
Понажимайте по ссылкам в верхнем меню и посмотрите как организованы URL в MVC по умолчанию. Страница About имеет адрес localhost:55515/Home/About (у вас порт может отличаться). Получается мы имеем такую структуру mysite<контроллер>/<действие>. Чтоже, вполне неплохо.
Что нам нужно
Как я уже сказал, мне необходим сайт с несколькими информационными страницами, каталогом аксессуаров и специальной страницей, которая будет получать и выводить данные из 1С. ОК, попробуем для начала реализовать наши статические страницы, сверстаем MasterPage, пропишем нужные стили и добьемся их работы. Конечно в более сложном приложении следовало бы начать с разработки бизнес логики, подумать над тем как мы будем хранить данные, все это написать и только потом приступать к интерфейсу. Но в нашем случае проект маленький, поэтому этой последовательностью можно пренебречь.
Облегчаем себе жизнь при написании кода
public static class AppHelper
<
public static string ContentRoot
<
get
<
string contentVirtualRoot = «
/Content» ;
return VirtualPathUtility.ToAbsolute(contentVirtualRoot);
>
>
В нем мы объявили статическое свойство ContentRoot – путь к нашему контенту, пути к директориям с изображениями и css файлами, а также 2 статических метода, ImageUrl и CssUrl, которые принимают имя файла и возвращают соответствующий путь к нему в нашем приложении. Для того чтобы воспользоваться нашим классом изменим тег link подключающий стили в Site.Master на следующий:
И не забудьте переместить Site.css в созданную директорию /Content/Css, отделим статический контент по его типу. Теперь если мы перекомпилируем наш проект, то путь пропишется вполне корректно:
link href =»/Content/css/Site.css» rel =«stylesheet» type =«text/css» />
На данном этапе мы написали свой Helper для прописывания правильного пути к изображениям и таблицам стилей. Далее рассмотрим как вообще мы можем работать с HTML и что нам предлагается.
Работа с HTML
Microsoft для облегчения написания кода предлагает HtmlHelper. Это класс с набором статических методов, который позволяет рендерить необходимые HTML-теги. Например, чтобы вывести картинку, достаточно написать
На странице это будет выглядеть как
Если мы воспользуемся нашим AppHelper для вычисления пути к картинке, то мы напишем так:
=Html.Image(AppHelper.ImageUrl( «logo.png» ), «Alt text» ) %>
Этот код уже сгенерирует правильную картинку и пропишет нужный путь:
img src =»/Content/Images/logo.png» alt =«Alt text» />
Ещё из интересных методов – это Html.ActionLink:
Этот метод сгенерирует ссылку на метод «About» контроллера «Номе» с текстом «О нас»
Можно и более «современными» средствами написать тот же код используя Lambda Expressions:
Что здесь происходит, думаю понятно по синтаксису.
Маленький хинт: чтобы не писать каждый раз пространство имен ITService.Controllers, пропишем его в web.config в секции system.web > pages > namespaces > :
Отдельно стоит упомянуть формы. С ними нам теперь прийдется работать достаточно в явном виде (никаких Postback, помните?). Простейшая форма будет выглядеть так:
ASP.NET Routing
Что такое роутеры? Роутеры позволяют нам работать с URL, которые не указывают на физические файлы на нашем сервере, вместо этого путь разбирается на параметры, которые мы уже используем в нашем приложении. Так же определенную часть пути мы может сопоставить с определенным контроллером и его методом. Такая модель используется по умолчанию, но мы можем задавать соответствия, которые удобны нам. С одной стороны, это похоже на старый добрый URL-Rewriting, о котором уже писали подробно на хабре в статье, но это только с одной стороны. На самом деле это разные вещи. Если мы используем UrlRewriting, то запрос вида mysite.com/products/product1 преобразуется при выполнении к mysite.com/products.aspx?id=product1. Нативно мы не можем генерировать URL, которые бы соответствовали нашим правилам перезаписи URL. Поэтому, если мы где-то изменим логику и поменяем шаблоны адресов, нам прийдется ручками править все места, где эти URL генерируются. В MVC никаких преобразований не происходит, так как сам без проблем разбирает путь, который ему передается.
Вся работа с Роутерами в MVC организована в Global.asax.cs. Заглянем туда в нашем проекте и увидим следующее:
Как видим, мы в коллекцию роутеров, которыми оперирует наше приложение добавляем свой. С именем Default, прописываем маску URL и создаем анонимный тип, в котором прописываем параметры по умолчанию. Изменения мы будем сюда вносить, когда перейдем непосредственно к реализации. В тоже время, если вас устраивает такая схема формирования адресов, то почему бы и нет? Можно оставить все как есть и это тоже будет работать.
Конец начала
Ну что, это была вступительная часть, в которой я постарался раскрыть самые базовые понятия о платформе ASP.NET MVC. Насколько это у меня получилось, судить вам. Я сам не являюсь экспертом в данной области, просто стало интересно самому, а заодно решил и с людьми поделиться, так как информации в рунете по этой теме совсем немного.
Хочу отметить, что мне важно ваше мнение обо всем, поэтому любой отзыв будет к стати. Если критика, то я, конечно, уверен, что она будет конструктивной 😉
В следующих статьях я перейду непосредственно к реализации задуманного приложения. Скорее всего, будет больше кода. И это меня не радует с таким форматированием, как на хабре 🙂