ASP.NET MVC представляет собой платформу для создания сайтов и веб-приложений с использованием паттерна (или шаблона) MVC (model — view — controller).
Работа над новой платформой была начата в 2007 году, а в 2009 году появилась первая версия. В итоге к текущему моменту (2012 год) уже было выпущено 4 версии платформы, а сам фреймворк обрел большую популярность по всему миру благодаря своей гибкости и адаптивности.
Шаблон MVC, лежащий в основе новой платформы, подразумевает взаимодействие трех компонентов: контроллера (controller), модели (model) и представления (view). Что же представляют эти компоненты?
Контроллер (controller) представляет класс, с которого собственно и начинается работа приложения. Этот класс обеспечивает связь между моделью и представлением. Получая вводимые пользователем данные, контроллер исходя из внутренней логики при необходимости обращается к модели и генерирует соответствующее представление.
Представление (view) — это собственно визуальная часть или пользовательский интерфейс приложения — например, html-страница, через которую пользователь, зашедший на сайт, взаимодействует с веб-приложением.
Differences Between ASP.NET WEBFORMS and ASP.NET MVC
Модель (model) представляет набор классов, описывающих логику используемых данных.
Общую схему взаимодействия упрощенно можно представить следующим образом:
ASP.NET MVC и ASP.NET Web Forms
ASP.NET MVC является в некотором роде конкурентом для традиционных веб-форм и имеет по сравнению с ними следующие преимущества:
- Разделение ответственности . В MVC приложение состоит из трех частей: контроллера, представления и модели, каждая из которых выполняет свои специфичные функции. В итоге приложение будет легче поддерживать модифицировать в будущем.
- В силу разделения ответственности приложения mvc обладают лучшей тестируемостью . И мы можем тестировать отдельные компоненты независимо друг от друга.
- Соответствие протоколу HTTP . Приложения MVC в отличие от веб-форм не поддерживают объекты состояния (ViewState). Ясность и простота платформы позволяют добиться большего контроля над работой приложения
- Гибкость . Вы можете настраивать различные компоненты платформы по своему усмотрению. Изменять какие-либо части конвейера работы MVC или адаптировать его к своим нуждам и потребностям.
В то же время не стоит однозначно сбрасывать со счетов ASP.NET WebForms. Поскольку она также имеет свои сильные стороны, например, модель событий, которая будет ближе тем разработчикам, которые ранее занимались созданием клиентских приложений.
В традиционных веб-формах вы имеете контроль над разметкой и можете в реальном времени в визуальном редакторе Visual Studio увидеть, как будет выглядеть та или иная страница. При работе с MVC Visual Studio подобного не позволяет делать.
В любом случае вы вольны выбирать ту платформу, которая приходится вам больше по душе. И если у вас написаны объемные проекты с применением традиционных веб-форм, возможно, стоит продолжать с ними работать. Тем более, что ASP.NET Web Forms еще не умирает и также продолжает развиваться.
ASP NET Core MVC tutorial
Источник: metanit.com
ASP.NET MVC на реальном примере. Теория и вступление.
Команда Microsoft очень интенсивно развивает свои продукты и средства для разработчиков. На эту тему уже и выхлопы шуточные были, по поводу выхода новых версий фреймворков. Разработчики, которые работают в крупных компаниях, ввязаны в большие проекты в общем-то без особого энтузиазма на это смотрят, так как такие махины нельзя в короткие сроки перевести на новую версию.
Может быть чревато как всплыванием багов, так и изменением всей структуры проекта, что делать не всегда получается легко. Сказанное выше, к сожалению (или к счастью), меня не касается и это дает мне возможность использовать все самое новое без оглядки на бекграунд. Проекты довольно таки обозримые, часто переводятся на новую версию безболезненно, и новые фичи начинаю внедрять уже при реализации следующей задачи в пректе. На момент внедрения это, конечно, вносит некий хаос в код, так как в разных кусках кода используются разные принципы (например, внедрение LINQ), но последующий рефакторинг кода приводит все к единому виду и все приходит в норму.
К чему все это?
Одним из таких нововведений является ASP.NET MVC — реализация шаблона Model-View-Controller под платформу .NET. Попробуем разобраться что же это такое, зачем нужно, и применим наши знания на простом, но реальном приложении.
Принцип работы MVC
- Model – это в общем-то вся бизнесс логика нашего приложения. В ней находятся классы, которые отвечают за наши данные (сущности), манипулируют ними, записывают в базу данных и читают от туда, а так же за взаимодействие между самими сущностями. Если наше приложение небольшое, то, скорее всего, мы прямо здесь и будем работать с данными. Если же проект более крупный, содержит много логики, то лучше вынести логику, и работу с данными в отдельные проекты (сборки). А когда столкнемся с совсем крупным приложением, то прийдется и физически выносить на другие сервера (Application Server).
- View отвечает за взаимодействие с пользователем (UI). Посредством него мы будем выводить наши данные клиенту, реализовывать интерфейс для их редактирования и многое другое. Но только то что связано с отображением. Никакой логики!
- Controller – это наше связующее звено между первыми двумя компонентами. Controller Получает данные о нашем запросе серверу, как-то эти данные обрабатывает (например получает значения из отправленной формы) и передает их в Model. После обработки или получения данных он выбирает каким же именно способом мы отобразить данные клиенту (нужный View).
Что нам это дает полезного? Мы получаем полный контроль над выводимым 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С, хочется, чтобы клиент мог, зайдя на сайт и введя номер своей квитанции, увидеть состояние ремонта: готов не готов, все ли отремонтировали по гарантии или за что-то прийдется доплатить.
Подготовка к работе
Для начала у вас должена быть установлена Microsoft Visual Studio 2008 (если не ошибаюсь, то должна подойти и Express редакция), .NET Framework 3.5, а так же сам ASP.NET MVC (на момент написания статьи доступен Preview 3). После успешной установки всего добра создадим наш проект. File -> New -> Project… В открывшемся окне выбираем в Project Types язык на котором пишете и тип проекта Web, среди предложеных шаблонов нам нужен ASP.NET MVC Web Application. У меня проект называется «ITService».
Далее нам предложит создать 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, пропишем нужные стили и добьемся их работы. Конечно в более сложном приложении следовало бы начать с разработки бизнес логики, подумать над тем как мы будем хранить данные, все это написать и только потом приступать к интерфейсу. Но в нашем случае проект маленький, поэтому этой последовательностью можно пренебречь.
Облегчаем себе жизнь при написании кода
Если заглянуть в наш Site.master, то мы увидим, что путь к css, наприме, там прописан относительный, т.е. ../../Content/Site.css. Нам это не подходит, так как вложенность наших страниц будет разная, и ссылка будет теряться, нужно исправить её на путь от корня. Для CSS можно было бы конечно и ручками прописать, но забегая наперед скажу, что у нас ещё и картинки будут на сайте. Каждый раз писать к ним достаточно длинный путь скучно, поэтому, сделаем Helper. Создадим папку Helpers, в неё добавим класс AppHelper со следующим кодом:
public static string CssUrl( string cssFile)
string result = string .Format( «/» , CssRoot, cssFile);
return result;
>
>
В нем мы объявили статическое свойство ContentRoot – путь к нашему контенту, пути к директориям с изображениями и css файлами, а также 2 статических метода, ImageUrl и CssUrl, которые принимают имя файла и возвращают соответствующий путь к нему в нашем приложении. Для того чтобы воспользоваться нашим классом изменим тег link подключающий стили в Site.Master на следующий:
< link href =»» rel =«stylesheet» type =«text/css» />
И не забудьте переместить Site.css в созданную директорию /Content/Css, отделим статический контент по его типу. Теперь если мы перекомпилируем наш проект, то путь пропишется вполне корректно:
На данном этапе мы написали свой Helper для прописывания правильного пути к изображениям и таблицам стилей. Далее рассмотрим как вообще мы можем работать с HTML и что нам предлагается.
Работа с HTML
Microsoft для облегчения написания кода предлагает HtmlHelper. Это класс с набором статических методов, который позволяет рендерить необходимые HTML-теги. Например, чтобы вывести картинку, достаточно написать
На странице это будет выглядеть как
Если мы воспользуемся нашим AppHelper для вычисления пути к картинке, то мы напишем так:
Этот код уже сгенерирует правильную картинку и пропишет нужный путь:
Ещё из интересных методов – это Html.ActionLink:
Этот метод сгенерирует ссылку на метод «About» контроллера «Номе» с текстом «О нас»
Можно и более «современными» средствами написать тот же код используя Lambda Expressions:
(x => x.About(), «О нас» ) %>
Что здесь происходит, думаю понятно по синтаксису.
Маленький хинт: чтобы не писать каждый раз пространство имен ITService.Controllers, пропишем его в web.config в секции < system.web >< pages > < namespaces >:
< add namespace =«ITService.Controllers» />
Теперь подобные ссылки можно писать короче:
(x => x.About(), «О нас» ) %>
Отдельно стоит упомянуть формы. С ними нам теперь прийдется работать достаточно в явном виде (никаких Postback, помните?). Простейшая форма будет выглядеть так:
Для работы с тегом from нам необходимо использовать директиву using и в области её действия прописать все поля формы. Это обеспечит нам закрывающийся тег . Ещё же объявление Html.Form(x => x.Index()) указывает на то, что форма будет отправлена методу «Index» контроллера HomeController. Считаю, что довольно таки здоров придумали.
Я вначале, когда увидел эту смесь html и серверных частей кода – пришел в ужас, думаю, все приплыли. Здавствуй снова классический ASP, где этой вермишели было полно. А вот все же не так уж страшно. Это совсем не то, что кажется на первый взгляд, когда начинаешь с ним работать. Все эти средства действительно мощные.
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. Насколько это у меня получилось, судить вам. Я сам не являюсь экспертом в данной области, просто стало интересно самому, а заодно решил и с людьми поделиться, так как информации в рунете по этой теме совсем немного.
Хочу отметить, что мне важно ваше мнение обо всем, поэтому любой отзыв будет к стати. Если критика, то я, конечно, уверен, что она будет конструктивной 😉
В следующих статьях я перейду непосредственно к реализации задуманного приложения. Скорее всего, будет больше кода. И это меня не радует с таким форматированием, как на хабре 🙂
* Весь код в статье был подсвечен, насколько это удалось, при помощи Source Code Highlighter .
Источник: habr.com
What is ASP.NET MVC?
Ранее мы обсудили MVC в общих чертах, а в этой главе поговорим о том, как его использовать в разработке веб-приложений ASP.NET. Компания Microsoft представила ASP.NET MVC в 2007 году, а первый стабильный релиз появился двумя годами позже. Стоит отметить, что реализация MVC свободно доступна в исходных кодах — Microsoft выпустила весь фреймворк MVC под лицензией Apache 2.0, что позволяет любому желающему изучать его, модифицировать и даже распространять сделанные изменения.
Движок Представления ASP.NET MVC
ASP.NET MVC первоначально разрабатывался как технология применяемая для представлений в WebForms (базовая технология ASP.NET), но в более поздних версиях предоставлял возможность быстрой замены движка представлений ASP.NET MVC на специально разработанный и Microsoft даже разработал один такой, названный Razor, который был выпущен совместно с ASP.NET MVC version 3 в 2011 году. На сегодняшний день, Razor является наиболее часто используемым движком представлений, совместно с WebForms, также существует ряд альтернативных движков разработанных сообществом, например Brail, NDjango, SharpTiles и многие другие. В этом руководстве мы сделаем акцент на Razor, потому что он действительно хорош и достаточно прост для начала.
Что означает Core?
Вы возможно заметили что это руководство называется «Руководство по ASP.NET MVC Core», но почему Core? Изначально .NET framework, вместе с компонентами ASP.NET, был выпущен как проприетарное программное обеспечение (ПО с закрытым исходным кодом) в 2002 году. Позднее, в Microsoft решили, что они хотят создавать .NET framework как программное обеспечение с открытым исходным кодом поддерживающее основные операционные системы: Windows, OS X и Linux. Они назвали его «.NET Core framework» и выпустили его в 2016 году, а затем последовало множество быстрых новых выпусков со множеством улучшений.
На сегодняшний день .NET Core framework надежен как и традиционный .NET framework и совместим с большинством операционных систем, а также имеет лучшую производительность и более короткий цикл выпуска обновлений, что означает более быстрое устранение ошибок и реализации новых возможностей чем в традиционном .NET framework. Так что, если у вас нет необходимости в использовании «устаревшей» функциональности реализованной исключительно в традиционном .NET framework, вам следует всегда применять .NET в варианте Core!
Заключение
Теперь вы знаете немного больше о MVC и о его реализации в .NET, переходите к следующей статье где мы обсудим различия ASP.NET MVC и первоначального движка представлений ASP.NET: ASP.NET WebForms.
This article has been fully translated into the following languages:
Is your preferred language not on the list? Click here to help us translate this article into your language!
Источник: asp.mvc-tutorial.com