Microsoft asp net mvc 4 runtime что это за программа и нужна ли она
Серия статей "История одного проекта" написана с использованием MVC 3. В этой статье будем переходить на MVC 4.
Задача
Просто или правильно
1. Меняем строки файла конфигурации:
2. Добавляем новый параметр приложения PreserveLoginUrl:
3. Обновляем nuget-пакеты. Благо теперь появилась новая опция –reinstall, которая при необходимости удалит пакет и потом заново установит его.
4. В файле проекта надо поменять ProjectTypeGuids. Выгружаем проект, открываем файл проекта для редактирования и меняем:
После этого сохраняем файл и даем команду перезагрузить проект.
5. И напоследок, если ваше приложение содержит сторонние сборки ссылающиеся на MVC фреймворк, то следует обновить еще и эту часть в файле конфигурации:
После этого ваш проект должен откомпилироваться и запуститься. У меня не получилось с первого раза, мне пришлось еще немного повозиться. В основном с установкой правильных версий nuget-пакетов под новый MVC 4.
Хочется верить, что у вас всё получилось с первого раза и поэтому продолжим.
WebSecurity и SimpleMembershipProvider
SimpleMembershipProvider на сайте MSDN описан так:
“Предоставляет поддержку для задач членства на веб-сайте, например создания учетных записей, удаления учетных записей и управления паролями.”
“Вспомогательный класс WebSecurity рекомендуется использовать для управления пользовательскими учетными записями, паролями и другими задачами членства. Класс SimpleMembershipProvider также может управлять членством; тем не менее, это не рекомендуется делать ввиду того, что WebSecurity предоставляет более простой способ управления членством. Класс SimpleMembershipProvider предназначен для разработчиков, которым требуется более точно контролировать членство.”
Таким образом, чтобы сайт работал быстрее и управление стало проще – нужно использовать новые возможности. Это я и собираюсь сделать.
Обновление базы данных
Во первой части цикла статей ИОП “Музей Юмора”, в которой речь идет о данных я рассказывал, как при помощи утилиты aspnet_regsql.exe добавить Memebership-функционал. Сейчас я намерен поступить наоборот, то есть удалить этот функционал из базы.
Итак, запустим эту самую утилиту:
На этот раз я выберу опцию “Remove”.
Придётся сначала “вручную” очистить все связанные таблицы. У меня получилось затратить на чистку не более пяти минут. Вот база “до” чистки:
А вот уже после того, как отработала утилита:
Обратите внимания, что также все StoredProcedures были удалены. Если вы делаете удаление “вручную”, то есть без использования утилиты, то не забудьте удалить всё что было ей установлено.
Самое интересное
В новом шаблоне сайта для MVC 4 есть папка Filters, в которой есть файл InitializeSimpleMembershipAttribute.cs. Этот файл содержит класс атрибута, установка которого на контроллере AccountController гарантирует, что перед использованием Membership (вход на сайт или регистрация), если еще нет инфраструктуры для работы Membership, то будут созданы все необходимые для этого таблицы в базе данных. Если вы не будете использовать на своем сайте вход/регистрацию, то эта инфраструктура (таблицы) не появятся в вашей базе.
Теперь посмотрим на что случится, если просто запустить сайт:
Собственно этого я и ждал. Запустим процесс обновления базы, я это делаю из Package Manager Console:
Запускаю еще раз сайт - работает, но только теперь сайт и понятия не имеет, что такое Membership. Вернемся к ранее упомянутому атрибуту InitializeSimpleMembershipAttribute.
Я его немного доработал, чтобы сразу при создании базы данных запускался процесс создания пользователя (меня).
Все изменения начинаются в строке 32 и заканчиваются в строке 59. Я постарался всё описать в комментариях. Запустил, проверил – да, действительно работает. Остается только перейти на страницу смены пароля и поменять на более “правильный”.
Аббревиатура MVC расшифровывается как Model-View-Controller (Модель-Представление-Контроллер) и представляет собой архитектурный паттерн, очень популярный в области веб-разработки.
- Полный контроль над HTML-разметкой
- Полный контроль над URL-адресами
- Лучшая концепция разделения
- Расширяемость
- Тестируемость
MVC паттерн
Хотя паттерн Model-View-Controller (Модель-Представление-Контроллер) распространился в веб-среде только с появлением в 2003 году Ruby on Rails, возник он в сообществе разработчиков Smalltalk еще в 1970-х годах.
В MVC паттерн входят 3 компонента:
- Model (Модель) – домен, на основе которого строится ваше программное обеспечение. Если бы вы создавали блог, вашими моделями были бы пост и комментарий. Иногда термин "модель" может обозначать конкретную модель представления – отображение домена для конкретной цели демонстрации в пользовательском интерфейсе.
- View (Представление) – визуальное отображение модели в определенном контексте. Представление обычно является результирующей разметкой, которую фреймворк передает веб-браузеру, как например, HTML-разметка, представляющая пост блога.
- Controller (Контроллер) – координатор, который обеспечивает связь между представлением и моделью. Контроллер отвечает за обработку входных данных, оказывающих влияние на работу модели, и решает, какое действие должно выполняться, к примеру, передача представления или перенаправление на другую страницу. В продолжение примера публикации блога – контроллер может искать самые последние комментарии для публикации (модель) и передавать их в представление для показа.
На рисунке 1.3 показано взаимодействие этих трех компонентов.
Рисунок 1-3: Компоненты MVC паттерна. Контроллер получает пользовательские входные данные, обращается к подходящей модели, а затем передает ее в представление. И контроллер, и представление зависят от модели, а модель не зависит ни от представления, ни от контроллера.
Близость к протоколу
Концепция разделения
Тестируемость
Аббревиатура MVC расшифровывается как Model-View-Controller (Модель-Представление-Контроллер) и представляет собой архитектурный паттерн, очень популярный в области веб-разработки.
- Полный контроль над HTML-разметкой
- Полный контроль над URL-адресами
- Лучшая концепция разделения
- Расширяемость
- Тестируемость
MVC паттерн
Хотя паттерн Model-View-Controller (Модель-Представление-Контроллер) распространился в веб-среде только с появлением в 2003 году Ruby on Rails, возник он в сообществе разработчиков Smalltalk еще в 1970-х годах.
В MVC паттерн входят 3 компонента:
- Model (Модель) – домен, на основе которого строится ваше программное обеспечение. Если бы вы создавали блог, вашими моделями были бы пост и комментарий. Иногда термин "модель" может обозначать конкретную модель представления – отображение домена для конкретной цели демонстрации в пользовательском интерфейсе.
- View (Представление) – визуальное отображение модели в определенном контексте. Представление обычно является результирующей разметкой, которую фреймворк передает веб-браузеру, как например, HTML-разметка, представляющая пост блога.
- Controller (Контроллер) – координатор, который обеспечивает связь между представлением и моделью. Контроллер отвечает за обработку входных данных, оказывающих влияние на работу модели, и решает, какое действие должно выполняться, к примеру, передача представления или перенаправление на другую страницу. В продолжение примера публикации блога – контроллер может искать самые последние комментарии для публикации (модель) и передавать их в представление для показа.
На рисунке 1.3 показано взаимодействие этих трех компонентов.
Рисунок 1-3: Компоненты MVC паттерна. Контроллер получает пользовательские входные данные, обращается к подходящей модели, а затем передает ее в представление. И контроллер, и представление зависят от модели, а модель не зависит ни от представления, ни от контроллера.
Содержание
После выпуска сервера Internet Information Services 4.0 в 1997 году, компания Microsoft начала исследовать возможность новой модели веб-приложения, которая удовлетворит жалобы на ASP, особенно связанные с отделением оформления от содержания, и которая позволит писать «чистый» код [3] . Работа по разработке такой модели была поручена Марку Андерсу, менеджеру команды IIS, и Скотту Гатри, поступившему на работу в Microsoft в 1997. Андерс и Гатри разработали первоначальный проект в течение двух месяцев, и Гатри написал код первоначального прототипа во время рождественских каникул 1997 года. [4]
Первоначальный проект назывался «XSP»; Гатри объяснил в интервью 2007 года, что «всегда спрашивают, что означает буква X. В то время она ничего не значила. XML начинается с неё; XSLT начинается с неё. Все клевое начинается с X, поэтому мы его так и назвали.» [3] Прототип XSP был написан на Java, так как на тот момент у Microsoft не было Java-подобной технологии. В то время уже предполагалось (небезосновательно, как выяснилось в дальнейшем), что лицензирование Java для Microsoft не будет продлено в 2003 году (в 2003 истекал срок выданной Sun Microsystems лицензии). В 1999 компанией Майкрософт было решено построить платформу с общеязыковой средой исполнения Common Language Runtime (CLR) и на её основе развить технологии. В ней, как и в Java, использовались программирование по принципам ООП, сборка мусора и другие возможности [5] . Гатри описал это решение как «огромный риск», так как успех новой разработки был связан с успехом CLR, которая, как и XSP, находилась на ранней стадии разработки.
Введение
Совершенно понятно, что если сформировать web-страницу, описав ее структуру средствами HTML, она будет совершенно статична в смысле содержимого. То есть при просмотре в браузере она будет нести в себе точно ту же информацию, что была в нее записана в момент создания, и переданные пользователем данные не могут быть использованы для модификации содержимого отображаемых ему страниц: он сможет увидеть только то, что предварительно было записано в конечный набор файлов.
Но что, если мы хотим отобразить на странице текущий курс евро или прогноз погоды? Если мы написали страницу HTML вчера, сегодня она уже устареет. Следовательно, мы должны уметь создавать динамические страницы. Динамическое наполнение страницы – это информация, содержание которой определяется тем, кому она предназначена, и которая отличается от просмотра к просмотру. Оно позволяет обеспечить двусторонний обмен информацией – от клиента к серверу и обратно.
Динамическими принято называть web-страницы, которые перед отправкой клиенту проходят цикл обработки на сервере. В самом простом случае это может быть некоторая программа, которая модифицирует запрашиваемые клиентом статические страницы, используя параметры полученного запроса и некоторое хранилище данных. Даже при такой примитивной организации «неразрешимая» задача из предыдущего абзаца обретает очевидное решение: достаточно подготовить всего одну статическую страницу – шаблон – и перед отправкой страницы программно подставлять в него значение, полученное сегодня из банка или метеобюро.
Для решения это проблемы Microsoft была предложена альтернатива – ISAPI(Internet Server Application Programming Interface)-расширения и фильтры. Вместо исполняемых файлов используются DLL – библиотеки. Код DLL находится в памяти все время и для каждого запроса создает не процессы, а нити исполнения. Все нити используют один и тот же программный код. ISAPI –приложение выполняется в процессе IIS-сервера. Это позволяет повысить производительность и масштабируемость.
ISAPI-расширения можно создавать в Visual Studio C++ 6.0, пользуясь мастером.
У ISAPI тоже есть недостатки, относящиеся к разработке. Если мы меняем исходный код dll, мы должны его откомпилировать и поместить в исполняемую директорию сервера. Но так как предыдущий вариант dll находится в памяти, необходимо остановить сервер, чтобы получить доступ на изменение файла. В это время клиенты не смогут получить в сервера ни один документ, и, конечно, будут не удовлетворены.
Скриптовые языки, исполняющиеся на стороне сервера – php и asp. Технология asp была разработана Microsoft в 90-х годах.
Выполнение кода asp поддерживается ISAPI-расширением сервера. В диалоге конфигурации сервера IIS определяются способы обработки файлов с различными расширениями. Для обработки URL-адреса с расширением в установках сервера определен файл asp.dll. Файлы asp отправляются к нему на обработку. На вход поступает asp, а на выходе имеем поток HTML-кода.
Пример файла asp:
Тег сигнализирует asp, что в нем находится код, который он должен обрабатывать на сервере. Выполняется скрипт на языке, который указан в директиве Language. Оператор Response.Write записывает текст в выходной поток сервера, таким образом, он становится частью HTML-страницы, отправленной пользователю.
Скриптовые языки не поддерживают строгую типизацию. Что это значит? Вы можете не описывать переменную до ее использования и можете присваивать ей значения разных типов. Это удобно, но создает почву для ошибок. Например, у вас есть переменная x1, и вы присваиваете ей значение 1, но вы сделали опечатку и по ошибке написали x2=1. Будет создана новая переменная x2, а значение x1 не изменится. В языке со строгой типизацией компилятор заметит, что переменная x2 не описывалась, и выдаст ошибку.
Шаблоны дизайна, темы и скины позволяют независимо дизайн всего сайта отдельно от его функциональности, темы включают графику и каскадные таблицы стилей.
Возможность прекомпиляции позволяет обнаружить ошибки до загрузки страниц на сервер. Можно не хранить на сервере исходные страницы aspx, тем самым защищая свою интеллектуальную собственность.
Процесс инсталляции
Системные требования – процессор с минимальной скоростью 600 МГц, 128 МБ памяти и 1.3 ГБ дискового пространства. После инсталляции нужно будет зарегистрировать свою установку, это совершенно бесплатно.
У WebMatrix инсталлятор размером всего 1.2 Мб, но у него меньше возможностей, чем у VWD. Но, в общем, эти среды разработки похожи. У WebMatrix есть неприятная особенность – она дает запрос на сохранение во время закрытия файлов, которые не редактировались. VWD Express позволяет одним нажатием кнопки открыть Web-интерфейс конфигурирования проекта. В VWD работает технология IntelliSense, которая автоматически предлагает возможные в данном месте элементы кода.
IIS(Internet Information Server) находится на инсталляционном диске Windows 2000/XP, но предустановлен только на серверах. Его можно установить, зайдя в Control Panel->Add or Remove Programs->Add/Remove Windows Components. Компьютер попросит вас вставить инсталляционный диск.
IIS может понадобиться, если вам нужен полноценный сервер для работы в интернет, а не просто на своем компьютере или в локальной сети или вы решили набирать текст в обычном редакторе. Для работы на своем компьютере во все эти среды разработки встроен сервер Cassini, который первоначально появился как часть WebMatrix. Символ WebMatrix – планета Сатурн, а Кассини — известный исследователь Сатурна. Предыдущие версии Visual Studio требовали наличия IIS, но теперь Cassini встроен и в Visual Studio 2005, что позволяет работать даже в Windows XP Home Edition.
Примеры будут даваться как для WebMatrix, так и Visual Studio. Некоторые примеры требуют VWD Express или Visual Studio.
Сообщества разработчиков.
Первый проект
Пока что страница в бразере пустая.
Но исходный код этой страницы не пустой. Программа сгенерировала код для вас.
Адаптивный рендеринг
Вместо этого вы можете использовать meta-тег viewport, чтобы явно указать браузеру ширину, высоту и масштаб для визуализации контента. Вы также можете сконфигурировать meta-тег viewport под рендеринг на основе возможностей устройства:
Media-запросы CSS При разработке сайта для нескольких платформ вы, как правило, хотите, чтобы мобильные пользователи видели представление, отличное от того, которое видят пользователи настольных браузеров. Обычно функциональность практически одинакова, но стиль и отображение контента различаются. С помощью media-запросов CSS можно по условиям применять конкретные CSS-стили в зависимости от возможностей браузера, запрашивающего ваш веб-сайт:
Этот media-запрос будет применять включенные стили, только когда тип media является screen, но не print, и максимальная ширина области, в которой визуализируется сайт, будет не более 850 пикселей. Эта методика позволяет изменять стиль контента как угодно в зависимости от возможностей браузера.
Имея дело с мобильными браузерами, вы всегда должны учитывать ограниченную полосу пропускания мобильной связи. В целом, когда вы используете мобильное устройство, вы не подключены к Wi-Fi или другой высокоскоростной сети, поэтому, рассчитывая свой сайт на обслуживание мобильных устройств, делайте это максимально эффективно. Например, если какие-то изображения не существенны для функциональности вашего сайта, не включайте их в мобильные представления. Если же изображения действительно нужны, позаботьтесь об их корректных размерах, т. е. отправляйте изображения, подогнанные под размеры экрана того устройства, на котором они будут отображаться. Если с помощью CSS можно просто указывать изображения, то с помощью media-запросов можно определять изображения разных размеров на основе возможностей устройства и его браузера.
Когда нельзя обойтись использованием только CSS
Иногда модификации стилей недостаточно, чтобы сделать сайт визуализируемым и удобным на всех устройствах. В таких случаях единственный реальный вариант — создавать представления, адаптированные к типам браузеров и устройств, на которые вы ориентируетесь.
Как видно на рис. 3, я сделал копию _Layout.cshtml и переименовал ее в _Layout.mobile.cshtml согласно этому соглашению. Я выделил добавленную строку HTML, чтобы было четко понятно, какой _Layout.cshtml использовался для визуализации этой страницы. Когда сайт визуализируется в настольном браузере, ничего не меняется, но при визуализации сайта в мобильном браузере, как показано на рис. 4, вы можете видеть, что используется мобильная версия _Layout.cshtml.
Рис. 3. Специфичный для мобильных устройств _Layout.cshtml
Рис. 4. Представление, специфичное для мобильного браузера
Передача представлений, специфичных для браузеров По большей части больше нет нужды передавать в настольные системы специфичные для браузеров представления или контент. Однако, если вы уже некоторое время занимаетесь разработкой веб-сайтов, весьма вероятно, что вы писали особый код или CSS, чтобы заставить что-то работать в каком-то конкретном браузере. Именно в такой ситуации мы теперь находимся с мобильными браузерами, но проблема сложнее из-за огромного разнообразия мобильных платформ, каждая со своим браузером. И будто этого мало, мы сейчас имеем еще и концепцию «родных» сайтов. Уже не достаточно того, что сайт обеспечивает качественную визуализацию в мобильных браузерах; чтобы сайт считался совершенным, он должен полностью соответствовать «духу и букве» родных приложений, выполняемых на устройствах. Это требует передачи специфических представлений не только для мобильных браузеров в целом, но и для каждого мобильного браузера индивидуально.
При разработке сайта для нескольких платформ вы, как правило, хотите, чтобы мобильные пользователи видели представление, отличное от того, которое видят пользователи настольных браузеров.
Чтобы задействовать преимущества Display Modes, нужно сначала определить эти режимы в методе Application_Start в Global.asax, например:
Чтобы продемонстрировать Display Mode браузера iPhone, я сделал другую копию _Layout.cshtml и присвоил ей имя _Layout.iPhone.cshtml по соглашению об именовании, определенному при создании этого Display Mode. Затем я модифицировал ее, чтобы было очевидно, что при просмотре сайте с iPhone использууется разметка iPhone. Если я просматриваю сайт с настольного браузера или из эмулятора браузера Windows Phone, я не вижу своих изменений, но, как только я обращаюсь к сайту в браузере iPhone, модификации тут же проявляются, как показано на рис. 5.
Рис. 5. Представление, специфичное для iPhone
jQuery Mobile и jQuery.Mobile.MVC
Рис. 6. Представление jQuery Mobile с функциональностью переключения представлений
Шаблон проекта
Как я уже вскользь упоминал, это единственный шаблон, который изначально включает jQuery Mobile. Более того, он реализует jQuery Mobile во всех представлениях по умолчанию:
Читайте также: