Курсы mvc. Охота на мифический MVC

- Не понимаю, почему люди так восхищаются этим Карузо? Косноязычен, гугнив, поёт - ничего не разберешь!
- А вы слышали, как поёт Карузо?
- Да, мне тут кое-что из его репертуара Рабинович напел по телефону.

Детектив по материалам IT. Часть первая

Я осознаю, что писать очередную статью на тему Модель-Вид-Контроллер это глупо и вредно для «кармы». Однако с этим «паттерном» у меня слишком личные отношения – проваленный проект, полгода жизни и тяжелой работы «в корзину».


Проект мы переписали, уже без MVC, просто руководствуясь принципами – код перестал быть похож на клубок спагетти и сократился наполовину (об этом позже, в обещанной статье про то, как мы применяли «принципы» в своем проекте). Но хотелось понять, что же мы сделали не так, в чем была ошибка? И в течении долгого времени изучалось все, что содержало аббревиатуру MVC. До тех пор пока не встретились исходные работы от создателя – Трюгве Реенскауга…


И тогда все встало на свои места. Оказалось что фактически на основе принципов мы пере-изобретали «original MVC». А то, что зачастую преподносится как MVC, не имеет к нему никакого отношения… впрочем также как и к хорошей архитектуре. И судя по тому сколько людей пишет о несостоятельности «классического MVC», спорит о нем и изобретает его всевозможные модификации, не одни мы столкнулись с этой проблемой.


Более 30 лет собранные в MVC идеи и решения остаются наиболее значимыми для разработки пользовательских интерфейсов. Но как ни странно, несмотря на существующую путаницу и обилие противоречивых трактовок, разработчики продолжают довольствоваться информацией «из вторых рук», черпая знания о MVC из википедии, небольших статей в интернете и фреймворков для разработки веб-приложений. Самые «продвинутые» читают Мартина Фаулера. И почему-то почти никто не обращается к первоисточникам. Вот этот пробел и хотелось бы заполнить. И заодно развеять некоторые мифы.



Мифы: MVC создавался для языка SmallTalk

Концепция MVC была сформулирована Трюгве Реенскаугом (Trygve Reenskaug) в результате его работы в Xerox PARC в 1978/79 годах. Как правило создание MVC связывают с языком SmallTalk, но это не совсем так. На самом деле Реенскауг работал в группе, занимавшейся разработкой портативного компьютера "для детей всех возрастов" Dynabook под руководством Алана Кэя (Alan Kay).


Чтобы оценить масштаб и революционность того проекта, нужно иметь ввиду что это были годы, когда для работы с ЭВМ требовалось штудировать многостраничные мануалы и иметь ученую степень. Задача, которую пытался решить Алан Кэй, состояла в том, чтобы сблизить компьютер и рядового пользователя, «сломать» разделяющую их стену. Он хотел обеспечить пользователя средствами, которые были бы предельно простыми и удобными, но при этом давали бы возможность управлять компьютером и сложными приложениями.


Именно тогда/там закладывались основы графического интерфейса, формировалось понятие "дружелюбного интерфейса". А также разрабатывался язык SmallTalk, вместе с концепциями объектно-ориентированного программирования, чтобы неподготовленный пользователь “мог понимать и писать программы”. Вот как описывает увиденное в Xerox PARC в 1979 году Стив Джобс – How Steve Jobs got the ideas of GUI from XEROX (from 6.30)


Проект велся около 10 лет, группой очень сильных разработчиков. Найденные в результате решения, подходы, принципы и в области пользовательских интерфейсов, и в области объектно ориентированного программирования и вообще в разработке больших и сложных компьютерных систем были в какой-то степени проссумированы Реенскаугом и составили основу MVC. Так что MVC это действительно прежде всего совокупность направляющих архитектурных идей. В SmallTalk-80 эти идеи всего лишь получили свою первую значимую реализацию. Причем сделано это было уже после ухода Реенскауга из Xerox PARC и без его участия.


К сожалению в течении долго времени о «реальном MVC» не было практически никакой доступной информации. Первая серьезная публикация от создателей появилась лишь 10 лет спустя – "A Cookbook for Using the Model-View-Controller User Interface Paradigm in Smalltalk-80 ". Даже Фаулер упоминает, что он изучал MVC по работающей версии SmallTalk – "у меня был доступ к работающей версии Smalltalk-80, чтобы я мог изучить MVC. Я не могу сказать, что это исследование было тщательным, но оно позволило мне понять некоторые аспекты решения, которые другие описания объяснить не смогли" .


Так что не удивительно появление «мифов» и разнообразных трактовок. Проблема заключается в том, что многие «вторичные» источники описывают MVC не только в искаженном, но еще и в обманчиво-упрощенном виде, как правило в виде некой формальной схемы.


В результате многие действительно считают MVC схемой или паттерном (из-за чего постоянно возникает вопрос – какая же из множества существующих схем «правильная» и почему их так много?). В более продвинутом варианте MVC называют составным паттерном, то есть комбинацией нескольких паттернов, работающих совместно для реализации сложных приложений (тут обычно упоминаются Observer, Strategy и Composite). И лишь немногие понимают, что MVC это прежде всего набор архитектурных идей/принципов/подходов, которые могут быть реализованы различными способами с использованием различных шаблонов...


К последним относится в частности Мартин Фаулер. Вот что он пишет: “MVC часто называют паттерном, но я не вижу особой пользы воспринимать его как паттерн, поскольку он включает в себя множество различных идей. Разные люди читают про MVC в различных источниках и извлекают от туда разные идеи, но называют их одинаково - «MVC». Это приводит к большой путанице и кроме того служит источником недоразумений и непониманию MVC, как будто бы люди узнавали про него через «испорченный телефон»…. Я уже потерял счет сколько раз я видел что-то, описываемое как MVC, которое им не оказывалось.” [ GUI Architectures]


Рискну предположить, что одна из причин «испорченного телефона» заключается в том, что большинство вторичных источников «за кадром» оставляют самое главное – собственно сами архитектурные идеи, заложенные в MVC его создателями, и те задачи, которые они пытались решить. Как раз все то, что позволяет понять суть MVC и избежать огромного количества подводных камней и ошибок. Поэтому в данной статье я хочу рассказать о том, что обычно остается «за кадром» – MVC с точки зрения заложенных в него архитектурных принципов и идей. Хотя схемы тоже будут. Вернее с них и начнем.


Но сначала ссылки. Исходный доклад Реенскауга – "The original MVC reports ". Позже Реенскауг все это более четко сформулировал и оформил в своей последующей работе “The Model-View-Controller (MVC). Its Past and Present ”. Возможно кому-то будет интересна страница, где собраны записи Ренскауга, относящиеся к тому периоду, с его комментариями - MVC XEROX PARC 1978-79 .


Уже упоминавшаяся первая публикация о MVC в языке SmallTalk-80 от разработчиков только в улучшенном качестве "A Description of the Model-View-Controller User Interface Paradigm in the Smalltalk-80 System " (Glenn Krasner и Stephen Pope). Хорошим дополнением служит также статья “Applications Programming in Smalltalk-80. How to use Model-View-Controller ” (автор SteveBurbeck учавствовал в разработке компилятора SmallTalk для IBM на основе Smalltalk-80, а также в разработке MacApp). Ну и если кто-то хочет полного погружения – “Smalltalk-80. The Interactive Programming Environment ” от знаменитой Адель Голдберг в дискуссиях с которой Реенскаугом и создавались термины Model, View, Controller.

Схемы MVC

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


Итак, несмотря на то, что MVC трактуется и изображается очень по разному, во всем этом многообразии все же можно выделить общее «ядро». Общим является то, что везде говорится о неких трех частях - Модели, Виде и Контроллере, которые связаны между собой определенным образом, а именно:

    Модель ничего не знает ни о Виде, ни о Контроллере, что делает возможным ее разработку и тестирование как независимого компонента. И это является главным моментом MVC.

    Вид отображает Модель. И значит, он каким-то образом должен получать из нее нужные для отображения данные. Наиболее распространены следующие два варианта: 1) Активный Вид , который знает о Модели и сам берет из нее нужные данные. 2) Пассивный Вид , которому данные поставляет Контроллер. В этом случае Вид с Моделью никак не связан.


    Видов может быть несколько - они могут по разному отображать одни и те же данные, например в виде таблицы или графика, или же отвечать за отображение разных частей данных из Модели.

  1. Контроллер является пожалуй самым неоднозначным компонентом. Тем не менее общим является то, что Контроллер всегда знает о Модели и может ее изменять (как правило в результате действий пользователя).

А также он может осуществлять управление Видом/Видами (особенно если их несколько) и соответственно знать о Видах, но это не обязательно.


Отсюда мы получаем базовые (максимально упрощенные) схемы двух наиболее часто встречающихся разновидностей MVC. Перечеркнутой линией обозначена необязательная связь Контроллера с Видом.



Вот так базовая схема выглядит у Фаулера: "Основные связи между Моделью, Видом и Контроллером. (Я называю их основными, потому что на самом деле Вид и Контроллер могут быть связанными друг с другом непосредственно. Однако, разработчики в основном не используют эту связь.)":



Далее. Модель, как и Вид, тоже может быть Пассивной либо Активной. Пассивная Модель никак не воздействует ни на Вид ни на Контроллер. В этом случае все изменения Модели отслеживаются Контроллером и он же отвечает за перерисовку Вида, когда это необходимо.


Но обычно, под MVC все таки подразумевают вариант с Активной Моделью .


«Активная Модель» оповещает о том, что в ней произошли изменения. И делает она это посредством шаблона Наблюдатель , рассылая уведомления о изменениях всем своим «подписчикам». «Активный Вид» подписывается на эти сообщения сам и таким образом знает когда нужно заново считать из модели нужные ему данные и обновиться. В случае «Пассивного Вида», подписчиком является Контроллер, который затем уже обновляет Вид.


Шаблон Наблюдатель позволяет Модели с одной стороны информировать Вид или Контроллер о том что в ней произошли изменения, а с другой фактически ничего о них «не знать» (кроме того что они реализуют некий заданный интерфейс «подписчика») и тем самым оставаться независимой. Это называется слабым связыванием и считается вторым ключевым моментом MVC.


Именно поэтому, когда говорится, что MVC это составной шаблон, то в первую очередь в качестве одного из его компонентов упоминается паттерн Наблюдатель . На диаграммах слабое связывание принято рисовать пунктирной стрелкой, но многие это правило игнорируют.


Таким образом, более продвинутые «схемы MVC» будут выглядеть так:



Замечание: встречаются авторы, которые в термины Пассивная и Активная модель вкладывают совсем иной смысл. А именно то, что обычно принято называть Тонкой моделью (модель содержащая исключительно данные) и Толстой моделью (полноценная модель содержащая всю бизнес логику приложения).


Ну и последнее. Вообще говоря MVC, в любой своей разновидности, это прежде всего шаблон для разработки приложений с пользовательским интерфейсом и его главное назначение – обеспечить взаимодействие приложения с пользователем. Поэтому в полноценной MVC схеме (явно или неявно) должен присутствовать пользователь . И тут в основном встречаются две трактовки:




Замечание: нужно иметь ввиду, что вариант с Пассивным Видом , когда Вид никак не связан с Моделью и данные для отображения ему поставляет Контроллер, иногда называют MVC, а иногда выделяют в отдельную разновидность - MVP и тогда Контроллер переименовывают в Презентер .


Для иллюстрации всего вышесказанного несколько диаграмм «из интернета» (надеюсь стало понятнее почему они такие разные):



А теперь самое главное - как применяются, что обозначают и чему соответствует Модель Вид и Контроллер при написании приложений?


Тут можно выделить два кардинально отличающихся подхода, в каждом из которых Модель, Вид и Контроллер трактуются весьма различным образом.

«Трехуровневый MVC» от веб

Первый подход идет из веб-программирования, где MVC получил самое широкое распространение, и поэтому в нем максимально отразились свойственные веб-программированию черты. А именно, привязка к трехуровневой архитектуре «клиент–сервер–база данных» и преобладание скриптовых языков. В результате компоненты MVC формально привязываются к трем слоям архитектуры и получается что:

    Модель = База Данных
    Модель - это просто данные, которыми оперирует приложение

    Контроллер = Сервер
    Контроллер - это бизнес-логика приложения. Иногда еще говорят что контроллер это центр обработки всех запросов и принятия решений, а также промежуточный слой обеспечивающий связь модели и представления.

  1. Вид = Клиент (как правило тонкий)
    Вид - это пользовательский интерфейс. Причем интерфейс в этом случае, как правило, понимается в основном исключительно как «дизайн», просто набор графических элементов. Логика же работы этого интерфейса, как и логика работы с данными, выносится в Контроллер


Про неадекватность этого подхода написано уже так много, что это вошло даже в википедию (MVC. Наиболее частые ошибки). Хорошо и подробно возникающие при этом проблемы рассматриваются в статье, ставшей своего рода классикой " ". Поэтому постараюсь просто кратко просуммировать:

    Независимость Модели является главным в MVC. Если Модель тонкая, то есть содержит лишь данные, то возможность ее независимой разработки имеет мало смысла. Соответственно при таком подходе теряет смысл и сам MVC

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

    На практике Контроллеру в веб-приложении обычно соответствует один скрипт и вынесение всей бизнес-логики в Контроллер фактически означает еще и то, что большая часть приложения оказывается в одном скрипте. Отсюда и появился термин ТТУК - толстый тупой уродливый контроллер

  1. Поскольку, как правило, тонкой является не только Модель но также и Вид (тупой Вид или тупой интерфейс - Dumb GUI, Dumb View), то, как следствие, в Контроллер помимо всей бизнес-логики приложения помещается также еще и логика управления пользовательским интерфейсом. То есть, вместо разделения бизнес логики и логики представления при таком подходе получается их смешение.



Типичные ошибки: смешение в Контроллере бизнесс-логики и GUI-логики

Хорошая новость заключается в том, что «веб-вариант MVC», всего несколько лет назад бывший самым распространенным, сейчас активно сдает позиции. Плохо то, что он по прежнему распространен, только теперь не в явном, а в замаскированном виде. Поскольку за фразы (цитирую): "Модель это обмен данными с БД и т.п. Контроллер логика обработки этих данных и подготовка к View " сейчас активно «минусуют», то стали писать:

  • Модель - это данные и методы работы с ними
  • Контроллер - обработка действий пользователя и вводимой им информации

Дело в том, что в объектно-ориентированном приложении нет данных, а есть множество объектов и каждый из них содержит какие-то данные и методы работы с ними. В том числе и объекы доступа к базе данных (если они имеются). Поэтому когда определение Модели начинается со слова «данные», то оно в сущности имеет мало смысла и нередко в завуалированной форме подразумевает все тот же самый доступ к базе данных. В обработку же действий пользователя нередко помещается львиная доля бизнес логики и в результате по прежнему вся, или почти вся, логика приложения часто оказывается в Контроллере.

«Архитектурный MVC»

Второй подход гораздо ближе к первоисточникам. Поэтому разберем его подробнее.


Мартин Фаулер абсолютно прав, когда говорит что MVC это не паттерн, а набор архитектурных принципов и идей, используемых при построении пользовательских информационных систем (как правило сложных).


Архитектурные принципы мы постарались собрать и описать в статье " ". Если же говорить предельно кратко, то суть состоит в следующем: сложную систему нужно разбивать на модули. Причем декомпозицию желательно делать иерархически , а модули, на которые разбивается система, должны быть, по возможности, независимы или слабо связаны (Low coupling ). Чем слабее связанность, тем легче писать/понимать/расширять/чинить программу. Поэтому одной из основных задач при декомпозиции является минимизация и ослабление связей между компонентами.


Давайте посмотрим, как эти принципы применяются в MVC для создания первичной архитектуры (декомпозиции) пользовательских приложений. По сути в основе MVC лежат три довольно простые идеи:


«1» Отделение модели предметной области (бизнес логики) приложения от пользовательского интерфейса


Первая и основная идея MVC заключается в том, что любое пользовательское приложение в первом приближении можно разделить на два модуля - один из которых обеспечивает основной функционал приложения, его бизнес логику, а второй отвечает за взаимодействие с пользователем:



Тем самым мы получаем возможность разрабатывать модель предметной области , содержащую бизнес-логику системы и составляющую функциональное ядро приложения, не думая о том как именно она будет взаимодействовать с пользователем.


Задача же взаимодействия с пользователем выносится в отдельный модуль – пользовательский интерфейс и тоже может решаться относительно независимо.


Именно модель предметной области (Доменная Модель от английского domain model ) считается Моделью в «архитектурном MVC» (отсюда и термин). Поэтому так важно чтобы она была независимой и могла независимо разрабатываться и тестироваться.


"Сердцевиной идеей MVC, как и основной идеей для всех последующих каркасов, является то, что я называю «отделенное представление» (Separated Presentation). Смысл отделенного представления в том, чтобы провести четкую границу между доменными объектами, которые отражают наш реальный мир, и объектами представления, которыми являются GUI-элементы на экране. Доменные объекты должны быть полностью независимы и работать без ссылок на представление, они должны обладать возможностью поддерживать (support) множественные представления, возможно даже одновременно. Этот подход, кстати, так же был одним из важных аспектов Unix-культуры, позволяющий даже сегодня работать во множестве приложений как через командную строку, так и через графический интерфейс (одновременно)." - Фаулер


«2» Независимость Модели и синхронизация пользовательских интерфейсов за счет шаблона Наблюдатель


Вторая ключевая идея заключается в том, что для того, чтобы иметь возможность разрабатывать Модель независимо , необходимо ослабить ее зависимость от пользовательского интерфейса. И делается это, как уже упоминалось выше, за счет шаблона Наблюдатель .


Модель рассылает извещения об изменениях . Интерфейс подписывается на эти оповещения и таким образом знает, когда нужно заново считать данные из модели и обновиться. Благодаря этому мы получаем практически независимую Модель , которая ничего не знает о связанных с ней пользовательских интерфейсах, кроме того что они реализуют интерфейс «наблюдателя».


«3» Разделение Пользовательского Интерфейса на Вид и Контроллер.


Третья идея это просто второй шаг иерархической декомпозиции. После первичного разделения приложения на бизнес модель и интерфейс, декомпозиция продолжается на следующем иерархическом уровне и уже пользовательский интерфейс, в свою очередь, делится на Вид и Контроллер.



У меня сложилось впечатление, что суть этого деления мало кто понимает и соответственно может объяснить. Обычно приводят лишь стандартную обтекаемую формулировку, что Контроллер как-то реагирует на действия пользователя, а Вид отображает Модель (поэтому в большинстве реализаций именно Вид подписывается на извещения об изменениях Модели. Хотя, как уже говорилось, подписчиком может быть и Контроллер, либо Вид и Контроллер вместе).


Поскольку деление пользовательского интерфейса на Вид и Контроллер относится ко второму уровню иерархии , оно гораздо менее значимо чем первичное разделения приложения на доменную модель и интерфейс. Очень часто (особенно когда дело касается простых виджетов) оно вообще не делается и используется «упрощенный MVC », в котором имеется только Модель и единый UI-компонент, представляющий собой объединенный ВидКонтроллер. Более подробно об этом речь пойдет чуть позже.


«Архитектурный MVC» на первый взгляд выглядит вполне разумно. Но как только мы попытаемся применить его не к учебному примеру из трех классов а к реальной программе, то столкнемся с целым рядом проблем и вопросов, о которых редко пишут, но которые чрезвычайно важны. И касаются они не только пользовательского интерфейса, но и самой Модели. Так что предлагаю таки попробовать с ними разобраться и, наконец-то, "послушать Карузо", то есть обратиться к первоисточникам.

«Original MVC»: Реенскауг и SmallTalk-80

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


В общем случае Модель это один объект или множество объектов? И на самом ли деле Модель в «MVC-схеме» тождественна доменной модели, описывающей предметную область и бизнес-логику приложения?


То, что Модель реализует шаблон Наблюдатель явно указывает на то, что Модель это именно один объект. На это же указывает и то, что Вид и Контроллер должны знать о Модели (для того чтобы брать из нее данные и вносить изменения) и следовательно они должны содержать на нее ссылку. Но тогда, если считать, что под Моделью подразумевается доменная модель, мы вновь приходим к тому что все ядро приложения оказывается в одном объекте. Только теперь вместо толстого уродливого Контроллера, у нас появляется толстая Модель. Толстая Модель конечно лучше, поскольку она независима и в ней, по крайней мере, не смешивается бизнес логика с логикой GUI, но все равно такое решение сложно отнести к хорошей архитектуре.


Остается второй вариант - Модель это множество доменных объектов, совместно реализующих бизнес логику. Это предположение подтверждает и сам Реенскауг: "A model could be a single object (rather uninteresting), or it could be some structure of objects. " Но тогда остается открытым вопрос – кто реализует шаблон Наблюдатель , откуда берет данные Вид, куда передает команды пользователя Контроллер?


И вот здесь нередко встречается попытка обмануть самих себя путем примерно следующего рассуждения: "пусть Модель это множество доменных объектов, но… среди этого множества есть в том числе и «объект с данными», вот он-то и будет реализовывать шаблон Наблюдатель, а также служить источником данных для Вида." Эту уловку можно назвать «Модель в Модели». И по сути это еще один «завуалированный» вариант того, что «Модель это данные».


Тут можно сказать лишь одно: архитектура, в которой один модуль (Вид или Контроллер), должен «лезть» внутрь другого модуля (доменной модели) и искать там для себя данные или объекты для изменения очень нехорошо «пахнет». Получается что Вид и Контроллер зависят от деталей реализации доменной модели, и если структура этой самой модели изменится, то придется переделывать весь пользовательский интерфейс.


Для того же, чтобы понять «а как должно быть» предлагаю вновь обратится к «принципам». Когда говорилось о том, что систему надо разбивать на модули, слабо связанные друг с другом, мы не упомянули главное правило, позволяющее добится этой самой слабой связанности. А именно – модули друг для друга должны быть «черными ящиками». Ни при каких условиях один модуль не должен обращаться к объектам другого модуля напрямую и что либо знать о его внутренней структуре. Модули должны взаимодействовать друг с другом лишь на уровне абстрактных интерфейсов (Dependency Inversion Principle). А реализует интерфейс модуля как правило специальный объект - Фасад .


И если поискать какие же паттерны позволяют добится слабой связанности, то на первом месте будет находится именно паттерн Фасад , и только затем Наблюдатель и тд.


Ну а теперь схема из доклада Трюгве Реенскауга:



Пояснение: Поскольку во времена создания MVC интерфейсы компьютерных программ были в основном текстовыми, то есть, по сути представляли собой простейший вид редактора, то вместо термина «Пользовательский Интерфейс», который появился позже, Трюгве Реенскауг использует термин «Editor» (редактор).


Таким образом, ключевая идея MVC действительно состоит в том, что пользовательское приложение делится на два модуля – один из которых моделирует предметную область и реализует бизнес логику (доменная модель ), а второй отвечает за взаимодействие с пользователем (пользовательский интерфейс ). Но при этом Модель в «MVC схеме» вовсе не тождественна доменной модели (которая может быть сколь угодно сложной и состоять из множества объектов), а является всего лишь ее интерфейсом и фасадом .


Так что ни Вид ни Контроллер разумеется не должны знать о том, как устроен модуль предметной области (доменная модель), где и в каком формате там храняться данные, и как именно осуществляется управление. Они взаимодействуют лишь с интерфейсом и реализующим его объектом-фасадом , который предоставляет все нужные данные в нужном формате и удобный набор высокоуровневых команд для управления подсистемой, а также реализует шаблон Наблюдатель, для извещения о значимых изменениях в подсистеме. И если мы захотим поменять базу данных, использовать облако, или вообще собирать нужные нам данные из различных источников в сети… если внесем какие угодно изменения в бизнес логику приложения, но при этом оставим неизменным интерфейс-фасад, то ни Вид, ни Контроллер это никак не затронет. Мы имеем архитектуру устойчивую к изменениям.


И если уж рисовать схему MVC, то выглядеть она должна следующим образом:



Давайте рассмотрим данную схему подробнее. Традиционно в клиент серверных приложениях главным считается сервер. Он предоставляет услуги/сервисы и решает в каком виде это должно быть реализовано. Соответственно интерфейс и фасад, как правило, определяются с точки зрения сервера. А клиенты под этот заданный формат подстраиваются.


На практике же более адекватной оказывается не сервер-ориентированная архитектура, а клиент-ориентированная. В ней фокус с сервера смещается в сторону клиента и интерфейс, вернее интерфейсы (и фасад или фасады), определяются исходя из потребностей клиентов. Вместо Предоставляемого Интерфейса (Provided Interface ) используются Требуемые Интерфейсы ().



Конкретные реализации могут варьироваться, но это не суть важно



Клиент ориентированный подход гораздо лучше соответствует Принципу разделения интерфейсов (Interface Segregation Principle ) поскольку в нем вместо единого для всех толстого ProvidedInterface используется множество тонких .


Если я не ошибаюсь, именно такой подход используется в архитектуре микросервисов. Там для взаимодействия с множеством сервисов введено понятие шлюза, который является ни чем иным как фасадом - “An API Gateway is a server that is the single entry point into the system. It is similar to the Facade pattern from object-oriented design. The API Gateway encapsulates the internal system architecture and provides an API that is tailored to each client . ” Building Microservices: Using an API Gateway .


Причем шлюз этот "вместо того чтобы обеспечивать общий единый для всех API, предоставляет различные API для каждого клиента (Rather than provide a one-size-fits-all style API, the API gateway can expose a different API for each client. For example, the Netflix API gateway runs client-specific adapter code that provides each client with an API that’s best suited to it’s requirements) " API Gateway .




Смотрим на фасад… Вот он тот самый клей (glue), объект посредник, прокси, фильтр, адаптер… связывающий между собой доменную модель и пользовательский интерфейс и поставляющий нужные данные в нужном/удобном формате.


Удивительно то, что кроме Реенскауга об этом почти никто не пишет. Хотя некоторые пере-открывают эту идею самостоятельно (пример можно посмотреть или раздел "Interface-Based Programming Techniques").


Особенно хорошо тема Моделей-интерфейсов раскрыта в статье одного из JavaGuru - Advanced MVC Patterns . Автор подчеркивает, что Модели это не данные, а исключительно интерфейсы/объекты-посредники/фильтры (Models as Proxies, Models as Filters), обеспечивающие удобный доступ к данным, которые могут находится где угодно – на разных машинах, в разных форматах: “О чем большинство программистов не думает, так это о том, что модели являются всего лишь интерфейсами. Они не должны содержать никаких данных!.. Модели-посредники расширяют охват и позволяют использовать уже существующие данные где бы они не находились ”.


Из-за того что фасад, присутствующий в original MVC, был «утерян», то его роль зачастую берет на себя Контроллер. Отсюда и проистекают представления что Контроллер находится «между Моделью и Видом», служит клеем между ними и обеспечивает нужные Виду данные.


На форумах нередко встречается вопрос - "Чем контроллер отличается от фасада?". Не смотря на наивность этот вопрос вполне закономерен и на него сложно дать разумный ответ поскольку во многих MVC фреймворках Контроллер на самом деле фактически является фасадом - «Фронт-Контроллер» .


Чем плохо такое решение? Если оно граммотно реализовано, то ничем. Но это в теории. А на практике нередко происходит путаница концепций и понятий и в результате Фронт-Контроллер с одной стороны злоупотребляет своими полномочиями и вместо делегирования команд начинает включать в себя реализацию бизнес логики. А с другой – продолжает одновременно выполнять функции пользовательского интерфейса и в результате в нем происходит уже упоминавшееся смешение «бизнес логики» и «GUI логики» (что собственно и делает его код похожим на огромную свалку).


Думаю, что пришло время перейти к Smalltalk. Smalltalk-80 создавался очень талантливыми людьми. С документацией в нем действительно имелись проблемы (тем более что «шаблонов проектирования» тогда еще не существовало) но вот с реализацией в основном все было хорошо и пользовательские интерфейсы, конечно же, не взаимодействовали с доменной моделью напрямую.


Между интерфейсом и доменной моделью (объектами языка SmallTalk) всегда располагался некий промежуточный класс/объект, который обеспечивал удобный интегральный доступ к доменным объектам их данным и методам. Вот эти-то промежуточные объекты (по сути выполняющие роль фасадов) и были в действительности Моделями в SmallTalk-80.


Например, для работы с кодом в Smalltalk использовались следующие GUI интерфейсы: Inspector, Browser, Workspace,…



Вот что пишет об их устройстве Glenn Krasner:


"Inspector в системе состоит из двух видов. ListView отображает список переменных (слева), а TextView показывает значение выбранной переменной (справа)… Моделью для этих видов служит экземпляр класса «Inspector »… Отдельный класс «Inspector » является посредником или фильтром для того чтобы обеспечивать доступ к любому свойству любого объекта. Использование промежуточных объектов между View и "actual " models является типичным способом изолировать поведение отображения от модели приложения...


Как и в случае Inspector, промежуточные объекты использовались также в качестве моделей для системных браузеров. Экземпляр класса «Browser » является моделью-посредником для каждого системного браузера... "


Замечание : название класса-посредника, описывающего промежуточный объект-фасад, обычно совпадало с названием отображающего его виджета. У Inspector промежуточная модель так и называлась «Inspector », а у Browser соответственно – «Browser ».


В случае Workspace, который был одним из простейших интерфейсов "моделью служил экземпляр StringHolder, который просто предоставлял текст, то есть строку с информацией о форматировании".



В конце своей статьи Krasner приводит список использовавшихся в SmallTalk Моделей (наследников базового класса Model): StringHolder , Browser , Inspector , FileModel , Icon … А также отмечает что "the models were almost always some sort of filter class ".


Позже в VisualWorks Smalltalk идея промежуточных Holder-ов была развита и реализована в полной мере. Там для доступа к каждой переменной, принадлежащей доменным объектам, используется свой интерфейс и фасад – ValueModel и ValueHolder. И, как не трудно догадаться, именно ValueModel реализует шаблон Наблюдатель , извещая GUI о происходящих «в домене» изменениях.



Типичные ошибки: обращение к доменным объектам напрямую

Из-за того, что разработчики не всегда хорошо понимают что стоит за всеми этими «моделями», а сами модели привыкли воспринимать как данные а не интерфейс, то это становится источником еще одной весьма распространенной и ресурсоемкой ошибки. Вместо того чтобы нужным образом всего лишь интерпретировать и адаптировать имеющиеся доменные данные с помощью моделей-посредников их начинают копировать в эти модели-посредники.


Например, ValueHolder это, как правило, всего лишь обертка вокруг уже существующей доменной переменной, он не должен содержать данные, он содержит ссылку на данные. Вот что пишут: "ValueModel does not need to actually store the value because it is already being stored by another model " (Understanding and Using ValueModels).


А вот цитата из статьи Advanced MVC Patterns : "Одна из самых распространенных ошибок, которую совершают люди когда используют Swing компоненты, заключается в копировании данных в модели этих Swing компонент. Правильный же способ состоит в том чтобы использовать уже существующие данные, адаптируя их при помощи фильтра… Запомните: никогда не копируйте данные которые можно просто интерпретировать! ".


Рассмотрим следующий простой пример. Если последовать интернет советам и для "добавления элементов в список" использовать код подобный этому (взято со StackOverflow и Adding and Removing an Item in a JList), то будет происходить как раз то самое копирование данных в модель списка:


Object items; // Доменный объект DefaultListModel model = new DefaultListModel(); JList list = new JList(model); for (int i = 0; i < items.length; i++){ // КОПИРОВАНИЕ доменных данных в модель списка! model.addElement(items[i]); }

Правильнее, конечно же, использовать данные массива просто обернув их в интерфейс ListModel (тем более что для этих целей создана уже почти готовая AbstractListModel):


// создаем фасад-адаптер к доменным данным, // который просто интерпретирует их нужным образом ListModel model = new AbstractListModel() { public int getSize() {return items.length;} public Object getElementAt(int index) {return items;} }; // передаем созданный фасад списку в качестве модели JList list = new JList(model);

И если надо объединить данные, отфильтровать или преобразовать каким-нибудь образом, то совершенно не нужны промежуточные массивы. Все делается непосредственно в модели-фасаде


Object items1; Object items2; // Доменные объекты // модель-фасад которая объединяет массивы ListModel model = new AbstractListModel() { public int getSize() { return items1.length + items2.length;} public Object getElementAt(int index) { return index

В случае небольших статических массивов преимущества не очевидны. Но в общем случае такой подход позволяет не только избегать копирования, но прежде всего защищает от проблем связанных с рассинхронизацией данных (если не полениться прописать методы извещающие слушателей об изменениях).


Ну а если хочется краткости, то тогда уж лучше так:


JList list = new JList(items);

В этом случае Джава сама сделает обертку-адаптер вместо копирования.


Типичные ошибки: копирование доменных данных в модели GUI-компонент

Ну и наконец мы может развеять главный миф, являющийся источником наибольшего количества проблем и ошибок.


Мифы: Модель в «MVC схеме» тождественна доменной модели и данным

Путаница возникает из-за того что одно и то же слово «Модель» используется в разных контекстах. Когда речь идет о декомпозиции и отделении бизнес-логики от пользовательского интерфейса , то под Моделью действительно понимается именно доменная модель , содержащая данные и логику работы с ними и обеспечивающая основной функционал приложения.


Но в контексте шаблонов и схем Модель это прежде всего интерфейс и реализующий его объект-посредник (фасад, адаптер, прокси) обеспечивающие удобный и безопасный доступ к доменным данным, которые могут находится где угодно. Реенскауг так и писал: "model object with a façade that reflects the user’s mental model ".


Когда MVC преподносится исключительно как «схема», то наличие «промежуточных моделей» кажется сложным и запутанным. Появляются вопросы ("Чем эти модели отличаются друг от друга?", “Как их правильно использовать?”), неоднозначные трактовки и множество возможностей сделать ошибку.


Но если понимать заложенные в MVC архитектурные идеи, то все становится предельно ясным: пользовательский интерфейс не имеет права обращаться к объектам доменной модели напрямую. А значит между доменной моделью и пользовательским интерфейсом должнен находиться фасад/посредник/адаптер..., и взаимодействовать пользовательский интерфейс (Вид и Контроллер) может только с ним. Возможностей сделать ошибку – ноль.


И по большому счету становится все равно каким термином этот объект-посредник называется и какая именно Model-View-Whatever разновидность MVC используется… Начинаешь видеть: какая задача решается, с помощью каких шаблонов и то, насколько хорошо или плохо это делается


В принципе на этом статью можно и закончить. Как уже упоминалось деление пользовательского интерфейса на Вид и Контроллер является наименее значимым, даже вспомогательным моментом. Но с другой стороны пользовательский интерфейс присутствует в каждом пользовательском приложении и иметь представление о подходах и идеях наработанных в этой области часто бывает полезно. К тому же именно вокруг Контроллера ведутся основные споры. Поэтому – , полностью посвященная именно этой теме.

Курс знакомит с особенностями создания Web-приложения с использованием ASP.NET MVC из.NET Framework 4.5., с возможностями повысить производительность и масштабируемость разработанных Web-приложений. Большое внимание уделяется сравнению технологий ASP.NET MVC и ASP.NET Web Forms и критериям выбора той или иной технологии.

Успешное окончание обучения по программе данного курса позволит специалистам:

  • Описывать основные технологии Microsoft в области web-разработки и выбирать наиболее подходящие для решения ваших задач.
  • Проектировать веб-приложения, удовлетворяющие различным требованиям.
  • Создавать модели шаблона MVC и реализовывать бизнес-логику в рамках этих моделей.
  • Создавать контроллеры MVC приложения, взаимодействующие с пользователями, моделями и представлениями данных.
  • Создавать представления MVC приложения, предназначенные для отображения и редактирования данных, а также для взаимодействия с моделями и контроллерами.
  • Создавать unit-тесты и использовать средства отладки Visual Studio 2012 при разработке веб приложений.
  • Создавать веб-приложения, использующие удобочитаемые для человека URL.
  • Использовать единый интерфейс и стиль в Вашем MVC приложении.
  • Ускорить взаимодействие с пользователем за счет кэширования и частичного обновления страниц.
  • Создавать клиентский код на JavaScript, использующий библиотеку jQuery.
  • Создавать защищенные MVC приложения.
  • Использовать web-сервисы Windows Azure из Вашего MVC приложения.
  • Разворачивать MVC приложения.

Цель курса

Формирование знаний и навыков создавать Web-приложения с использованием ASP.NET MVC из.NET Framework 4.5.

Целевая аудитория

Опытные web-разработчики , имеющие опыт создания приложений с использованием Visual Studio.

Необходимая подготовка

  • Курс 10267 «Введение в разработку веб-приложений с использованием Microsoft Visual Studio 2010» или эквивалентная подготовка.
  • Курс HTML и CSS. Уровень 1. Создание сайтов по стандартам W3C и переход на HTML 5 и СSS 3.

1. Обзор ASP.NET MVC 4.

  • Обзор веб технологий Microsoft.
  • Обзор ASP.NET 4.5.
  • Введение в ASP.NET MVC 4.

2. Проектирование веб приложения ASP.NET MVC 4.

  • Архитектурное проектирование Моделей.
  • Архитектурное проектирование Контроллеров.
  • Архитектурное проектирование Представлений.
  • Архитектурное проектирование приложения.

3. Разработка ASP.NET MVC 4 Моделей.

  • Создание MVC Моделей (Models).
  • Работы с данными.

4. Разработка ASP.NET MVC 4 Контроллеров.

  • Создание Контроллеров (Controllers) и их Методов (Actions).
  • Создание фильтров для методов (action filters).

5. Разработка ASP.NET MVC 4 Представлений.

  • Создание Представлений (Views) с использованием движка Razor.
  • Использование HTML Helpers.
  • Повторное использование кода в Представлениях.

6. Тестирование и отладка ASP.NET MVC 4 веб приложений.

  • Создание unit-тестов.
  • Конфигурирование обработки исключений.

7. Структурирование ASP.NET MVC 4 веб приложения.

  • Конфигурирование шаблонов url.
  • Создание навигационных элементов управления.

8. Применение стилей в ASP.NET MVC 4 веб приложении.

  • Использование шаблонов представлений.
  • Применение стилей CSS в MVC приложении.
  • Создание адаптивного пользовательского интерфейса.

9. Создание интерактивных страниц в ASP.NET MVC 4 веб приложении.

  • Использование AJAX и частичного обновления страниц.
  • Стратегия использования кэширования.

10. Использование JavaScript и jQuery для создания интерактивных страниц.

  • Размещение и запуск JavaScript на странице.
  • Использование jQuery и jQueryUI.

11. Ограничение доступа в ASP.NET MVC 4 веб приложении.

  • Аутентификация и авторизация.
  • Назначение ролей.

12. Безопасность в ASP.NET MVC 4 веб приложении.

  • Создание надежных сайтов.
  • Сохранение состояния.

13. Использование веб сервисов Windows Azure в ASP.NET MVC 4 веб приложении.

  • Введение в Windows Azure.
  • Проектирование и реализация web сервисов Windows Azure.
  • Использование веб сервисов Windows Azure в веб приложении.

14. Реализация WebAPI в ASP.NET MVC 4 веб приложении.

  • Разработка WebAPI.
  • Использование WebAPI в мобильных и веб приложениях.

15. Обработка запросов в ASP.NET MVC 4 веб приложении.

  • Использование модулей и обработчиков HTTP.
  • Использование Web Sockets.

16. Разворачивание ASP.NET MVC 4 веб приложения.

  • Разворачивание веб приложения.
  • Разворачивание MVC 4 приложения.

Получаемый документ

Удостоверение о повышении квалификации, или Сертификат. (В зависимости от категории слушателей и общей продолжительности программы)

Модуль 1: Изучение ASP.NET Core MVC

Microsoft ASP.NET Core MVC и другие веб-технологии ASP.NET Core могут помочь вам создавать и размещать динамические, мощные и расширяемые веб-приложения. ASP.NET Core, частью которого является ASP.NET Core MVC, является кроссплатформенной средой с открытым исходным кодом, которая позволяет создавать веб-приложения. Вы можете разрабатывать и запускать веб-приложения ASP.NET Core в Windows, macOS, Linux или на любой другой платформе, которая его поддерживает. ASP.NET Core MVC поддерживает гибкий, управляемый тестами цикл разработки. Он также позволяет использовать новейшие стандарты HTML и интерфейсные среды, такие как Angular, React и другие.

  • Обзор веб-технологий Microsoft
  • Обзор ASP.NET 4.x
  • Введение в ASP.NET Core MVC

Лабораторная работа: изучение ASP.NET Core MVC

  • Изучение приложения бритвенных страниц
  • Изучение приложения веб-API
  • Изучение приложения MVC
  • Понимать разнообразие технологий, доступных в веб-стеке Microsoft.
  • Опишите различные модели программирования, доступные для разработчиков в ASP.NET.
  • Выберите между ASP.NET Core и ASP.NET 4.x.
  • Опишите роль ASP.NET Core MVC в стеке веб-технологий и как использовать ASP.NET Core MVC для создания веб-приложений.
  • Различать модели MVC, контроллеры MVC и представления MVC.

Модуль 2. Разработка веб-приложений ASP.NET Core MVC

Microsoft ASP.NET Core MVC - это модель программирования, которую вы можете использовать для создания мощных и сложных веб-приложений. Тем не менее, все сложные проекты развития, и в частности крупные проекты, могут быть сложными и запутанными для полного понимания. Без полного понимания целей проекта вы не сможете разработать эффективное решение проблемы клиента. Вам необходимо знать, как определить набор бизнес-потребностей и спланировать веб-приложение Model-View-Controller (MVC) для удовлетворения этих потребностей. Созданный план проекта гарантирует заинтересованным сторонам, что вы понимаете их требования, и сообщает разработчикам о функциональных возможностях веб-приложения, его пользовательском интерфейсе, структуре и хранилище данных. Написав подробный и точный план проекта, вы можете обеспечить эффективное использование мощных функций MVC для решения бизнес-задач клиента.

  • Планирование на этапе разработки проекта
  • Проектирование моделей, контроллеров и представлений

Лабораторная работа: разработка веб-приложений ASP.NET Core MVC

  • Планирование классов моделей
  • Планирование контроллеров
  • Планирование видов
  • Архитектура и веб-приложение MVC
  • Планируйте общую архитектуру веб-приложения ASP.NET Core MVC и учитывайте такие аспекты, как управление состоянием.
  • Планируйте модели, контроллеры и представления, необходимые для реализации заданного набора функциональных требований.

Модуль 3. Настройка промежуточного программного обеспечения и служб в ASP.NET Core

ASP.NET Core - это фреймворк, который позволяет нам создавать различные приложения. В этом модуле вы узнаете, как использовать платформу ASP.NET Core для обработки запросов и ответов через существующее и настраиваемое промежуточное ПО, а также как настроить службы для использования в промежуточном ПО и во всех других частях приложения, таких как контроллеры. Промежуточное программное обеспечение - это сегмент кода, который можно использовать как часть конвейера запросов и ответов, который позволяет нам обрабатывать их в соответствии с любым соответствующим параметром. Это потенциально позволяет обрабатывать несколько отдельных запросов совершенно по-разному и получать отдельные ответы. Сервисы - это классы, которые предоставляют функциональные возможности, которые впоследствии можно использовать в разных частях приложения, без необходимости вручную отслеживать область действия в каждом отдельном местоположении и создавать какие-либо зависимости. Это делается с помощью внедрения зависимостей. Внедрение зависимостей - это метод, используемый в ASP.NET Core, который позволяет нам добавлять зависимости в код, не беспокоясь о создании объектов, сохранении их в памяти или передаче требуемых зависимостей. Это позволяет приложению стать более гибким и уменьшить потенциальные точки отказа при каждой смене службы.

  • Настройка Middlewares
  • Настройка сервисов

Лабораторная работа: настройка промежуточного программного обеспечения и сервисов в ASP.NET Core

  • Работа со статическими файлами
  • Создание собственного промежуточного программного обеспечения
  • Использование внедрения зависимости
  • Внедрение услуги в контроллер

После прохождения этого модуля студенты смогут:

  • Использовать существующее промежуточное ПО для настройки приложения ASP.NET Core.
  • Создавать свое собственное промежуточное программное обеспечение и используйте его для определения пользовательского поведения.
  • Понимать основные принципы, лежащие в основе внедрения зависимостей, и то, как они используются в ASP.NET Core.
  • Знать, как создать пользовательскую службу, настроить ее область действия и внедрить ее как в промежуточное ПО, так и в контроллеры ASP.NET Core MVC.

Модуль 4: Разработка контроллеров

ASP.NET Core MVC - это платформа для создания веб-приложений с использованием архитектурного шаблона Model-View-Controller (MVC). Контроллер по существу отвечает за обработку веб-запроса путем взаимодействия с моделью и последующей передачи результатов в представление. Модель представляет бизнес-уровень, иногда называемый доменом, и может включать объекты данных, логику приложения и бизнес-правила. Представление использует данные, которые оно получает от контроллера, для создания HTML или другого вывода, который отправляется обратно в браузер. В этом модуле вы узнаете, как разрабатывать контроллеры. Контроллеры являются центральными для приложений MVC. Понимание того, как работают контроллеры, крайне важно для возможности создавать соответствующие объекты модели, манипулировать ими и передавать их в соответствующие представления. Контроллер - это класс. Он содержит несколько методов. Эти методы называются действиями. Когда приложение MVC получает запрос, оно находит, какой контроллер и действие должны обработать запрос. Это определяется с помощью маршрутизации Uniform Resource Locator (URL). URL-маршрутизация является еще одной очень важной концепцией, необходимой для разработки приложений MVC. Среда ASP.NET Core MVC включает гибкую систему маршрутизации URL, которая позволяет вам определять правила отображения URL в ваших приложениях. Чтобы максимизировать повторное использование кода в контроллерах, важно знать, как писать фильтры действий. Вы можете использовать фильтры действий для запуска кода до или после каждого действия в веб-приложении, для каждого действия в контроллере или для других комбинаций действий контроллера.

  • Написание контроллеров и действий
  • Настройка маршрутов
  • Написание фильтров действий

Лаборатория: Разработка контроллеров

  • Добавление контроллеров и действий в приложение MVC
  • Настройка маршрутов с использованием таблицы маршрутизации
  • Настройка маршрутов с использованием атрибутов
  • Добавление файла действий

После прохождения этого модуля студенты смогут:

  • Добавьте контроллер в веб-приложение, которое реагирует на действия пользователя, указанные в проекте проекта.
  • Добавьте маршруты в ядро ​​маршрутизации ASP.NET Core и убедитесь, что URL-адреса удобны для пользователя в веб-приложении MVC.
  • Напишите код в фильтрах действий, которые выполняются до или после действия контроллера.

Модуль 5: Разработка видов

Представления являются одним из трех основных компонентов модели программирования Model-View-Controller (MVC). Вы можете определить пользовательский интерфейс для вашего веб-приложения, создав представления. Представление - это комбинация разметки HTML и кода C #, которая выполняется на веб-сервере. Поэтому, чтобы создать представление, вам нужно знать, как писать разметку HTML и код C # и использовать различные вспомогательные классы, встроенные в MVC. Вам также необходимо знать, как создавать частичные представления и компоненты представления, которые отображают фрагменты HTML, которые можно повторно использовать в вашем веб-приложении.

  • Создание видов с помощью синтаксиса Razor
  • Использование HTML Helpers и Tag Helpers
  • Повторное использование кода в представлениях

Лабораторная работа: разработка представлений

  • Добавление видов в приложение MVC
  • Добавление частичного вида
  • Добавление компонента просмотра

После прохождения этого модуля студенты смогут:

  • Создайте представление MVC и добавьте в него разметку Razor для отображения данных пользователям.
  • Используйте HTML-помощники и теги-помощники в представлении.
  • Повторно используйте разметку Razor в нескольких местах в приложении.

Модуль 6: Разработка моделей

Большинство веб-приложений взаимодействуют с различными типами данных или объектов. Например, приложение электронной коммерции управляет продуктами, корзинами, покупателями и заказами. Приложение социальной сети может помочь управлять пользователями, обновлениями статуса, комментариями, фотографиями и видео. Блог используется для управления записями блога, комментариями, категориями и тегами. Когда вы пишете веб-приложение Model-View-Controller (MVC), вы создаете модель MVC для моделирования данных для вашего веб-приложения. Внутри этой модели вы создаете класс модели для каждого типа объекта. Класс модели описывает свойства каждого типа объекта и может включать бизнес-логику, соответствующую бизнес-процессам. Следовательно, модель является фундаментальным строительным блоком в приложении MVC. В этом модуле вы узнаете, как создавать код для моделей.

  • Создание моделей MVC
  • Работа с формами
  • Проверить приложение MVC

Лабораторная работа: разработка моделей

  • Добавление модели
  • Работа с формами
  • Добавить проверку

После прохождения этого модуля студенты смогут:

  • Добавьте модель в приложение MVC и напишите в ней код для реализации бизнес-логики.
  • Используйте отображение и редактирование аннотаций данных.
  • Проверьте ввод пользователя с аннотациями данных.

Модуль 7: Использование Entity Framework Core в ASP.NET Core

Веб-приложения часто используют информацию, и им обычно требуется хранилище данных для этой информации. Рендеринг веб-страниц, использующих данные из хранилища данных, позволяет создавать веб-приложения, которые постоянно изменяются в ответ на пользовательский ввод, административные действия и публикации событий. Хранилище данных обычно представляет собой базу данных, но иногда используются другие типы хранилищ данных. В приложениях Model-View-Controller (MVC) вы можете создать модель, которая реализует логику доступа к данным и бизнес-логику. Кроме того, вы можете отделить бизнес-логику от логики доступа к данным с помощью репозитория. Репозиторий - это класс, который контроллер может вызывать для чтения данных из хранилища данных и записи данных в хранилище данных. При написании приложения ASP.NET вы можете использовать технологии Entity Framework Core (EF Core) и Language Integrated Query (LINQ), которые делают код доступа к данным очень быстрым для написания и простым для понимания. В этом модуле вы увидите, как создать управляемый базой данных веб-сайт в MVC.

  • Введение в Entity Framework Core
  • Работа с Entity Framework Core

Лабораторная работа: использование Entity Framework Core в ASP.NET Core

  • Добавление Entity Framework Core
  • Используйте Entity Framework Core для извлечения и хранения данных
  • Используйте Entity Framework Core для подключения к Microsoft SQL Server

После прохождения этого модуля студенты смогут:

  • Подключите приложение к базе данных для доступа и хранения данных.
  • Объясните EF Core.
  • Работа с Entity Framework Core.
  • Используйте EF Core для подключения к базе данных, включая Microsoft SQL Server

Модуль 8. Использование макетов, CSS и JavaScript в ASP.NET Core MVC

При создании веб-приложений вы должны применять единообразный внешний вид приложения. Вы должны включить согласованные разделы верхнего и нижнего колонтитула во все представления. Microsoft ASP.NET Core MVC включает такие функции, как стили и макеты каскадных таблиц стилей (CSS), которые улучшают внешний вид и удобство использования вашего веб-приложения. В ASP.NET Core MVC вы можете создавать интерактивные элементы HTML с помощью JavaScript. Вам нужно знать, как использовать JavaScript в вашем веб-приложении. Чтобы упростить добавление JavaScript в ваше веб-приложение, вам нужно знать, как использовать библиотеки, такие как jQuery.

  • Использование макетов
  • Использование CSS и JavaScript
  • Использование jQuery

Лабораторная работа: использование макетов, CSS и JavaScript в ядре ASP.NET

  • Применение макета и ссылок на него
  • Использование CSS
  • Использование JavaScript
  • Использование jQuery

После прохождения этого модуля студенты смогут:

  • Примените согласованную разметку к приложениям ASP.NET Core MVC.
  • Добавьте код JavaScript в ваше веб-приложение.
  • Используйте библиотеку jQuery в своем веб-приложении.

Модуль 9: Разработка на стороне клиента

При создании приложения важно знать, как разработать приложение как на стороне клиента, так и на стороне сервера. В этом модуле вы изучите клиентские инструменты, которые позволят вам создавать обширные веб-приложения в любом масштабе. Эти инструменты основаны на темах, описанных в модуле 8 «Использование макетов, CSS и JavaScript в ASP.NET Core MVC». В этом модуле вы узнаете, как использовать среду Bootstrap для стилизации вашего веб-приложения. Затем вы узнаете, как использовать Sass and Less, два распространенных препроцессора Cascading Style Sheets (CSS), которые добавляют в CSS такие функции, как переменные, вложенные правила и функции. Это значительно повышает удобство сопровождения сложных веб-приложений. Далее вы узнаете, как настроить исполнители задач, такие как Grunt и gulp, и как использовать их для компиляции файлов Sass во время сборки Microsoft Visual Studio. Вы узнаете, как использовать средство запуска gulp для выполнения связывания и минимизации файлов CSS и JavaScript, а также как настроить задачу-наблюдатель для компиляции файлов Sass во время написания кода без необходимости перестраивать решение. Наконец, вы изучите адаптивные инструменты дизайна, которые позволяют настраивать отображение вашего веб-приложения на основе возможностей и спецификаций веб-браузера или устройства. Вы научитесь писать медиа-запросы CSS, как использовать адаптивную сеточную систему Bootstrap и как применять макет флексбокса CSS к своим представлениям.

  • Применение стилей
  • Использование бегунов задач
  • Адаптивный дизайн

Лаборатория: Разработка на стороне клиента

  • Используйте gulp для запуска задач
  • Стилизация с использованием Sass
  • Использование Bootstrap

После прохождения этого модуля студенты смогут:

  • Используйте Bootstrap, Sass и Less в приложении Microsoft ASP.NET Core.
  • Используйте обработчики задач в приложении ASP.NET Core.
  • Убедитесь, что веб-приложение правильно отображается на устройствах с разными размерами экрана.

Модуль 10: Тестирование и устранение неисправностей

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

  • Тестирование приложений MVC
  • Реализация стратегии обработки исключений
  • Регистрация приложений MVC

Лабораторная работа: тестирование и устранение неисправностей

  • Тестирование модели
  • Тестирование контроллера с использованием поддельного репозитория
  • Реализация репозитория в проекте MVC
  • Добавить обработку исключений
  • Добавить запись

После прохождения этого курса студенты смогут:

  • Запускать модульные тесты для компонентов Model-View-Controller (MVC), таких как классы моделей и контроллеры, и найдите потенциальные ошибки.
  • Создать приложение Microsoft ASP.NET Core MVC, которое обрабатывает исключения плавно и надежно.
  • Запустить поставщиков журналов, которые приносят пользу вашим приложениям, и запускайте их, используя общий API ведения журналов.

Модуль 11: Управление безопасностью

Поскольку веб-приложения обычно ориентированы на пользователей, использующих только браузер, чтобы использовать приложение, вероятно, будет гораздо больше пользователей, чем в случае установленных приложений. Однако открытость веб-приложения означает, что безопасность всегда должна быть в центре вашего внимания при их создании. В качестве обеспечения безопасности вы должны решить, какие пользователи могут выполнять какие действия, одновременно защищая пользователей и ваше приложение от злонамеренных третьих лиц с возможным доступом к вашему приложению. Аутентификация - это использование нескольких параметров, чтобы убедиться, что пользователь является тем, кем он себя считает. Используя аутентификацию, вы можете выяснить, кто пользователь, и предоставить им соответствующий контент при использовании ваших приложений. Авторизация - это процесс, в котором уже авторизованному пользователю в приложении может быть предоставлен доступ к определенным действиям или ресурсам. Используя авторизацию, вы можете запретить пользователям доступ к конфиденциальным материалам, не предназначенным для них, или к выполнению действий, которые они не должны иметь. Наконец, в какой-то момент своей жизни ваши приложения могут подвергаться атакам злоумышленников. Они могут различаться по средствам и намерениям, но цена незащищенности может быть большой. Вы можете потерять потенциальных пользователей, которые пострадали, ценные данные могут быть ошибочно изменены, а в худшем случае все приложение может стать непригодным для использования. Решения для некоторых из самых популярных атак будут рассмотрены в этом модуле.

  • Аутентификация в ASP.NET Core
  • Авторизация в ASP.NET Core
  • Защита от атак

Лабораторная работа: управление безопасностью

  • Использовать личность
  • Добавить авторизацию
  • Избегайте атаки подделки межсайтовых запросов

После прохождения этого модуля студенты смогут:

  • Добавьте базовую аутентификацию в ваше приложение.
  • Настройте Microsoft ASP.NET Core Identity.
  • Добавьте базовую авторизацию в ваше приложение.
  • Используйте несколько разных подходов авторизации.
  • Знать, как работают эксплойты безопасности и как лучше защищаться от них

Модуль 12: Производительность и связь

Современные веб-приложения требуют сложного взаимодействия с пользователями. Пользователи часто запрашивают много данных за небольшой промежуток времени, а также ожидают соответствующих данных, как только они появятся в сети. Это может легко вызвать значительную нагрузку на неподготовленный сервер, что приведет к излишне сложным или повторным операциям и большой нагрузке на ваш сервер. К счастью, есть несколько способов уменьшить нагрузку. Кэширование позволяет хранить часто повторяющиеся запросы, предотвращая необходимость повторного выполнения одной и той же логики. Используя кеширование, вы можете повторно использовать уже загруженные данные и представить их пользователю. Это обеспечивает пользователю быстрое время отклика и уменьшает системные ресурсы, используемые при проведении логики для действия. Между тем состояние позволяет достичь состояния согласованности между различными запросами. Используя различные формы управления состоянием, вы можете преобразовать обычную веб-среду без сохранения состояния в ту, которая настраивается индивидуально для отдельных клиентов, при этом разные пользователи получают отдельную и релевантную работу в одном приложении. Наконец, SignalR - это структура, которая позволяет абстрагировать несколько различных протоколов связи в простой в использовании API, который позволяет легко создавать единый набор инструментов на сервере и клиенте для упрощения двусторонней связи. Это позволяет вам сосредоточиться на логике, которую вы хотите реализовать, в то же время позволяя вам не обслуживать определенные браузеры.

  • Государство управления
  • Двусторонняя связь

Лаборатория: Производительность и общение

  • Реализация стратегии кэширования
  • Управление государством
  • Двусторонняя связь

После прохождения этого модуля студенты смогут:

  • Реализация кэширования в приложении Microsoft ASP.NET Core.
  • Используйте технологии управления состоянием для улучшения взаимодействия с клиентом, предоставляя пользователю постоянный опыт.
  • Внедрите двустороннюю связь с помощью SignalR, позволяя серверу уведомлять клиента о важных событиях.

Модуль 13: Реализация веб-API

Большинство веб-приложений требуют интеграции с внешними системами, такими как мобильные приложения. Вам необходимо знать, как использовать веб-API для взаимодействия приложений с внешними системами. Вы можете использовать веб-API для реализации служб представления состояния (REST) в вашем приложении. Службы REST помогают снизить накладные расходы приложений и ограничить объем данных, передаваемых между системами клиента и сервера. Вам необходимо знать, как вызывать веб-API с помощью серверного кода и кода jQuery для эффективной реализации веб-API в стиле REST в вашем приложении.

  • Представляем веб-API
  • Разработка веб-API
  • Вызов веб-API

Лабораторная работа: реализация веб-API

  • Добавление действий и вызов их с помощью Microsoft Edge
  • Вызов веб-API с использованием серверного кода
  • Вызов веб-API с использованием jQuery

После прохождения этого модуля студенты смогут:

  • Создавайте сервисы с помощью ASP.NET Core Web API.
  • Вызовите веб-API из серверного кода и jQuery.

Модуль 14: Хостинг и Развертывание

Приложения ASP.NET Core MVC предназначены для предоставления услуг нескольким пользователям одновременно, при этом требуется только установка сервера и предоставление клиентам доступа к нему через браузеры. Это приводит к крайне желательным приложениям, которые не зависят от установки пользователем специального программного обеспечения и обеспечения его доступности для клиентов на самых разных машинах. Чтобы настроить приложение ASP.NET Core для производственной среды, вам необходимо скомпилировать код и сжать его, а затем настроить и запустить на выделенном сервере. Хостинг предполагает использование выделенного сервера для размещения скомпилированного приложения и предоставления его пользователям в качестве веб-службы. Существует множество различных технологий, которые можно использовать для размещения вашего приложения, и вы должны выбрать ту, которая соответствует вашим требованиям. Развертывание - это процесс, в котором код проекта компилируется, а затем передается на хост-сервер таким образом, чтобы он соответствовал требованиям среды хостинга. Microsoft Azure - это облачный сервис, предоставляемый Microsoft. Он может использоваться для размещения приложений ASP.NET Core и является популярным инструментом на рынке облачных технологий. Он предоставляет удобные сервисы, связанные с веб-приложениями, с несколькими вариантами выставления счетов в соответствии с требованиями.

  • Локальный хостинг и размещение
  • Развертывание в Microsoft Azure
  • Основы Microsoft Azure

Лабораторная работа: хостинг и развертывание

  • Развертывание веб-приложения в Microsoft Azure
  • Загрузите изображение в хранилище BLOB-объектов Azure

После прохождения этого модуля студенты смогут:

  • Разместить и развернуть приложение ASP.NET Core MVC на IIS.
  • Разместить и развернуть приложение ASP.NET Core MVC в Microsoft Azure.
  • Уметь использовать службы, предлагаемые Microsoft Azure, для улучшения возможностей ваших веб-приложений.

Сегодня речь пойдет о веб-программировании, в частности мы представим вам курсы ASP.NET MVC 5. Вообще, научиться программированию – задача посильная любому человеку, независимо от его образования и увлечений. Программист – одна из самых высокооплачиваемых профессий, а в современном мире еще и самая актуальная. На базе программ работают не только ваши компьютеры и смартфоны, но и практически вся бытовая техника, системы безопасности в супермаркетах и так далее. Именно поэтому, если вы хотите заняться саморазвитием и освоить новые навыки (для себя или для будущей карьеры – это значения не имеет), лучше всего выбрать программирование.

Сегодня мы подобрали для вас лучшие курсы ASP.NET MVC 5. На базе этого фреймворка Microsoft разрабатывает различные динамические веб-приложения с управлением данными. В качестве ресурса была выбрана Udemy, самая популярная платформа для онлайн-обучения, которая содержит 45000+ курсов и насчитывает 15 млн.+ студентов со всего мира.

Онлайн-курсы ASP.NET MVC 5

В чем преимущества онлайн-курсов ASP.NET MVC 5:
— обучение в удобном для вас ритме;
— постоянный доступ и возможность вернуться к непонятому материалу;
— возможность прочесть отзывы и заранее подобрать под себя курс;
— большой выбор, не ограничиваемый географическими рамками.

В подборке — три премиум курса с самым высоким рейтингом и положительными отзывами. Полный список находится .

Лучшие к урсы ASP.NET MVC 5 2017

  1. Полный курс ASP.NET MVC 5

Преподаватель: Мош Хамедани, идейный инженер программного обеспечения, входит в число лучших преподавателей на Udemy
Стоимость: 190$
Количество студентов: 16773+
Объем программы: 138 лекций; 7,5 часов
Уровень подготовки (требования для курса): C# (лямбда-выражения на минимальном уровне, LINQ); базовые знания веб-разработки (HTML, CSS, JavaScript и jQuery)

Чему вы научитесь?
— Понимать архитектурный шаблон MVC
— Создавать формы с валидацией со стороны сервера и клиента
— Использовать мощные плагины jQuery
— Использовать Entity для запроса и обновления данных
— Создавать и развертывать приложения
— Управлять зависимостями клиент-сервер
— Работать с AutoMapper
— Выполнять операции CRUD
— Создавать службы RESTful с помощью веб-API ASP.NET
— Аутентификация и авторизация с помощью веб-API ASP.NET
— Понимать и применять лучшие практики безопасности
— Создавать и настраивать конфигурации сборки
— Тестировать API с помощью PostMan

Программа курса довольно практичная, а манера обучения позитивная. 7,5 часов видеоматериалов примерно равняется прочтению учебника на 500 страниц. Все видео разделены на короткие фрагменты, чтобы вы смогли усваивать материал постепенно. Также в каждом разделе есть несколько упражнений на закрепление полученных знаний.

В рамках курса вы научитесь запускать приложение и базу данных, создавать сборки, сохранять настройки приложений, защищать эти настройки и строки подключения. Все это вы будете делать на примере реального приложения для видеотеки.

Курс рассчитан на новичков, но предполагает знание C# и веб-разработки. Курс очень популярный (16 тысяч студентов!) и имеет высокий рейтинг (4.6) Курсы C# можно найти , а курсы по веб-разработке .

  1. Проект на ASP.NET MVC 5 – CMS и корзина с поддержкой PayPal

Преподаватель: Воислав Ковачевич, веб-программист с огромным опытом и знаниями в области PHP, C#, ASP.NET MVC, OOP, HTML, JavaScript и т.д.
Стоимость: 30$
Количество студентов: 354+
Объем программы: 70 лекций; 9 часов
Уровень подготовки (требования для курса): Visual Studio 2015 Community; навыки работы в Visual Studio, базовые знания C#, MVC и веб-разработки (желательно, но не обязательно)

Чему вы научитесь?
— Работать с ASP.NET MVC и Entity Framework
— Создавать собственные приложения на ASP.NET MVC и Entity Framework

Если предыдущий курс был посвящен основам и теоретической части с небольшими практическими заданиями, то этот курс в корне отличается от него. Это практический курс по ASP.NET MVC 5 с использованием технологий Entity Framework и Bootstrap.

В программе курсе вы изучите множество техник и методик, которые сможете применить на практике, чтобы создавать сайты с использованием ASP.NET MVC и Entity Framework. В отличие от бесплатных курсов, здесь точно собрана вся актуальная информация, которую не придется выискивать самому.

  1. Создание сайта с подписками на базе ASP.NET MVC 5

Преподаватель: Йонас Фагерберг, профессиональный преподаватель, разработчик и консультант
Стоимость: 75$
Количество студентов: 354+
Объем программы: 239 лекций; 25,5 часов
Уровень подготовки (требования для курса): базовые знания MVC 5, HTML5 и CSS3, уверенное владение C#

Чему вы научитесь?
— Создавать реальную базу данных на коде с помощью Entity Framework
— Использовать валидацию на стороне клиента и сервера
— Использовать ASP.NET Identity для безопасности
— Создавать стили пользовательских интерфейсов с помощью CSS3 и Bootstrap
— Создавать сценарии для подписки на продукты с помощью регистрационных кодов
— Реализовать функцию сброса пароля
— Управлять пользователями и их подписками
— Добавлять и изменять, модели, виды и контроллеры для выполнения операций CRUD в базах данных
— Использовать JavaScript, jQuery и Ajax для создания отличных пользовательских интерфейсов с асинхронными вызовами служб
— Создавать отзывчивые сайты
— Реализовать альтернативный способ входа в приложение
— Регистрировать пользователей на сайте

Так же, как и предыдущий, это очень практический курс. Он предполагает наличие базовых знаний по MVC 5, поэтому перед началом советуем пройти первый курс в нашей подборке «Полный курс ASP.NET MVC 5» . Вам понадобятся знания HTML5 и CSS3 , а также .

За время курса вы научитесь создавать полнофункциональный сайт с подписками (членством) и двумя пользовательскими интерфейсами (для админа и для пользователя) на базе ASP.NET MVC 5 с помощью базы данных Entity Framework. Все объясняется пошагово, и вы выполняете все упражнения вместе с преподавателем, что повышает интерактивность обучения.

После прохождения курса, кроме сертификата, вы получите веб-приложение, которое можно будет добавить к резюме или разместить в портфолио на биржах фрилансеров типа UpWork – это реальный опыт, подтвержденный на деле.

Помните, что онлайн-курсы ASP.NET MVC 5 не только дают вам необходимые знания и расширяют возможности для карьерного роста, но и экономят ваше время и деньги. Выбирайте только самое лучшее с InBenefit и Udemy!

Александр - основатель проекта сайт «Веб-лаборатория успеха», созданного в поддержку начинающим и продолжающим интернет-предпринимателям.Убежденный трудоголик, за плечами которого профессиональный опыт руководства редакцией интернет-журнала, создания и управления собственным интернет-магазином. Основной род занятий: продвижение бизнесов (в т.ч. интернет-магазинов) через Facebook и Google Adwords. Основное увлечение: монетизация сайтов через инструменты партнерского маркетинга и Google Adsense. Личные подтвержденные рекорды: 3 миллиона посетителей блога в месяц.

Курс знакомит с особенностями создания Web-приложения с использованием ASP.NET MVC из.NET Framework 4.5., с возможностями повысить производительность и масштабируемость разработанных Web-приложений. Большое внимание уделяется сравнению технологий ASP.NET MVC и ASP.NET Web Forms и критериям выбора той или иной технологии.

Успешное окончание обучения по программе данного курса позволит специалистам:

  • Описывать основные технологии Microsoft в области web-разработки и выбирать наиболее подходящие для решения ваших задач.
  • Проектировать веб-приложения, удовлетворяющие различным требованиям.
  • Создавать модели шаблона MVC и реализовывать бизнес-логику в рамках этих моделей.
  • Создавать контроллеры MVC приложения, взаимодействующие с пользователями, моделями и представлениями данных.
  • Создавать представления MVC приложения, предназначенные для отображения и редактирования данных, а также для взаимодействия с моделями и контроллерами.
  • Создавать unit-тесты и использовать средства отладки Visual Studio 2012 при разработке веб приложений.
  • Создавать веб-приложения, использующие удобочитаемые для человека URL.
  • Использовать единый интерфейс и стиль в Вашем MVC приложении.
  • Ускорить взаимодействие с пользователем за счет кэширования и частичного обновления страниц.
  • Создавать клиентский код на JavaScript, использующий библиотеку jQuery.
  • Создавать защищенные MVC приложения.
  • Использовать web-сервисы Windows Azure из Вашего MVC приложения.
  • Разворачивать MVC приложения.

Цель курса

Формирование знаний и навыков создавать Web-приложения с использованием ASP.NET MVC из.NET Framework 4.5.

Целевая аудитория

Опытные web-разработчики , имеющие опыт создания приложений с использованием Visual Studio.

Необходимая подготовка

  • Курс 10267 «Введение в разработку веб-приложений с использованием Microsoft Visual Studio 2010» или эквивалентная подготовка.
  • Курс HTML и CSS. Уровень 1. Создание сайтов по стандартам W3C и переход на HTML 5 и СSS 3.

1. Обзор ASP.NET MVC 4.

  • Обзор веб технологий Microsoft.
  • Обзор ASP.NET 4.5.
  • Введение в ASP.NET MVC 4.

2. Проектирование веб приложения ASP.NET MVC 4.

  • Архитектурное проектирование Моделей.
  • Архитектурное проектирование Контроллеров.
  • Архитектурное проектирование Представлений.
  • Архитектурное проектирование приложения.

3. Разработка ASP.NET MVC 4 Моделей.

  • Создание MVC Моделей (Models).
  • Работы с данными.

4. Разработка ASP.NET MVC 4 Контроллеров.

  • Создание Контроллеров (Controllers) и их Методов (Actions).
  • Создание фильтров для методов (action filters).

5. Разработка ASP.NET MVC 4 Представлений.

  • Создание Представлений (Views) с использованием движка Razor.
  • Использование HTML Helpers.
  • Повторное использование кода в Представлениях.

6. Тестирование и отладка ASP.NET MVC 4 веб приложений.

  • Создание unit-тестов.
  • Конфигурирование обработки исключений.

7. Структурирование ASP.NET MVC 4 веб приложения.

  • Конфигурирование шаблонов url.
  • Создание навигационных элементов управления.

8. Применение стилей в ASP.NET MVC 4 веб приложении.

  • Использование шаблонов представлений.
  • Применение стилей CSS в MVC приложении.
  • Создание адаптивного пользовательского интерфейса.

9. Создание интерактивных страниц в ASP.NET MVC 4 веб приложении.

  • Использование AJAX и частичного обновления страниц.
  • Стратегия использования кэширования.

10. Использование JavaScript и jQuery для создания интерактивных страниц.

  • Размещение и запуск JavaScript на странице.
  • Использование jQuery и jQueryUI.

11. Ограничение доступа в ASP.NET MVC 4 веб приложении.

  • Аутентификация и авторизация.
  • Назначение ролей.

12. Безопасность в ASP.NET MVC 4 веб приложении.

  • Создание надежных сайтов.
  • Сохранение состояния.

13. Использование веб сервисов Windows Azure в ASP.NET MVC 4 веб приложении.

  • Введение в Windows Azure.
  • Проектирование и реализация web сервисов Windows Azure.
  • Использование веб сервисов Windows Azure в веб приложении.

14. Реализация WebAPI в ASP.NET MVC 4 веб приложении.

  • Разработка WebAPI.
  • Использование WebAPI в мобильных и веб приложениях.

15. Обработка запросов в ASP.NET MVC 4 веб приложении.

  • Использование модулей и обработчиков HTTP.
  • Использование Web Sockets.

16. Разворачивание ASP.NET MVC 4 веб приложения.

  • Разворачивание веб приложения.
  • Разворачивание MVC 4 приложения.

Получаемый документ

Удостоверение о повышении квалификации, или Сертификат. (В зависимости от категории слушателей и общей продолжительности программы)