ASP.NET MVC Framework
Гайдар Ильдарович Магдануров / Владимир Александрович Юнев
Рассмотрены основные принципы и возможности технологии ASP.NET MVC Framework и показаны способы ее практического использования при разработке веб-приложений. Описаны преимущества подхода разработки MVC и рассмотрена структура MVC-приложения. Приведено сравнение технологии WebForms и MVC Framework и рассмотрены вопросы их совмещения. Описаны модель и доступ к данным (технологии LINQ, Entity Framework и др.), контроллеры, представление и интерфейс приложения, механизмы маршрутизации и Ajax-функциональность. Уделено внимание вопросам тестирования веб-приложений. Рассмотрены особенности применения ASP.NET MVC 2 в Visual Studio 2010. Для программистов
| Жанры: | Интернет, Программирование |
| Серии: | - |
| Всего страниц: | 94 |
| ISBN: | 978-5-9775-0462-1 |
| Год издания: | 2010 |
| Формат: | Фрагмент |
ASP.NET MVC Framework читать онлайн бесплатно
ГЛАВА 1
Знакомство с MVC Framework
Первая глава книги посвящена знакомству с подходом разработки веб-приложений на платформе ASP.NET с использованием MVC Framework. Поскольку эта книга рассчитана на разработчиков с разным опытом создания программного обеспечения, прежде чем рассматривать подход к разработке веб-приложений на основе MVC Framework, мы поговорим об основных принципах архитектуры MVC. Прочитав эту главу, вы узнаете об основных компонентах MVC Framework и о том, как эти компоненты находят свое отражение в коде приложения.
Если вы уже знакомы в общих чертах с MVC Framework, можете смело пропустить эту главу и перейти к более детальному изучению составляющих MVC Framework в последующих главах.
Паттерн проектирования MVC
Аббревиатура MVC, давшая название MVC Framework, скрывает в себе всю суть архитектурного подхода построения приложений по принципу MVC: модель, представление и контроллер — это те компоненты, из которых состоит каждое приложение, созданное в этой парадигме.
Приложение, построенное с использованием паттерна проектирования MVC, разбивается на три слабосвязанных между собой логических компонента.
□ Модель — компонент приложения, отвечающий за взаимодействие с источником данных (база данных, XML-файлы, файловая система и т. п.), а также содержащий описание объектов, описывающих данные, с которыми работает приложение.
□ Представление — компонент, отвечающий за отображение пользовательского интерфейса — в случае веб-приложения HTML-разметки или других форматов данных, принимаемых вызывающим клиентом.
□ Контроллер — компонент, содержащий логику приложения. В контроллере описана логика взаимодействия с пользователем — в случае веб-приложения логика обработки HTTP-запросов к веб-приложению. Контроллер взаимодействует с объектами модели, которые, в свою очередь, влияют на представление.
Графическое представление архитектуры MVC приведено на рис. 1.1.
Важно отметить слабую связанность компонентов между собой. Компонент модель автономен и не зависит от реализации контроллеров и представлений, его реализация не зависит от реализации остальной части приложений.
С точки зрения контроллера и представления модель представляет собой черный ящик, из которого приходят или в которой помещаются определенные объекты. Говоря простым языком, модель предоставляет контроллеру и представлению некоторый контракт, в соответствии с которым все три компонента системы работают с данными в одинаковом формате.
Преимущество такого подхода можно продемонстрировать на примере из жизни. В свое время один из авторов книги работал над Windows-приложением для ведения небольшой складской базы. Это приложение было построено на базе Windows Forms, в полной мере подход MVC не использовался, однако в приложении был выделенный автономный компонент для работы с данными — модель. В дальнейшем, когда потребовалось создать веб-приложение для доступа к складской базе данных из внутренней сети и Интернета, сборка, содержащая компонент модель, была подключена к проекту веб-приложения и использовалась совместно с работающим на сервере Windows Forms-приложением. В дальнейшем этой же моделью данных воспользовались веб-службы, которые были разработаны поверх складской базы данных.
Компонент представление отображает состояние объектов модели, которое модифицируется контроллером. Представлению недоступны сведения о внутренней реализации контроллера, а также работа представления не зависит от того, каким образом было модифицировано состояние объектов модели. Задача представления очень проста — отображение актуального состояния объектов модели.
Компонент контроллер не зависит от внутренней реализации модели и представлений, используемых для визуализации состояния модели, с которой работает контроллер. Задача контроллера заключается в том, чтобы получить запрос от пользователя, обработать его и подготовить коллекцию данных, которые будут использованы представлением.
Независимость контроллера и представления позволяет просто заменять представления без необходимости модификации контроллера, что позволяет упростить модификацию системы и получить дополнительное преимущество — использование разных представлений для различных клиентов. На примере из жизни преимущества такого подхода продемонстрировать очень легко. Перед одним из авторов книги как-то встала задача создать версию веб-сайта для мобильных устройств. Поскольку сам проект был разработан с использованием подхода MVC, задачу удалось решить очень просто — в момент обращения к той или иной странице происходила проверка типа браузера пользователя, и в соответствии с этим автоматически подставлялось представление, оптимизированное под этот браузер. При этом не пришлось изменять логику самих контроллеров и URL-адреса.
История паттерна проектирования MVC
Подход к разработке программы с использованием разбиения на компоненты "модель", "представление" и "контроллер" был предложен в 1979 году норвежским ученым Тригве Ринскаугом, когда он работал в исследовательском центре Xerox в Пало Альто. Реализован подход был на языке Smalltalk для графических интерфейсов настольных систем. Тогда веб-приложения еще даже не маячили на горизонте, однако проблема разделения программной логики и интерфейса стояла остро — различные операционные системы предлагали разные подсистемы для отображения графического интерфейса, и при необходимости переноса приложений между платформами возможность повторного использования программной логики при изменении только кода, работающего с графической подсистемой, оказалась весьма кстати.
