Asp net mvc что это
Общие сведения об ASP.NET MVC
Узнайте о различиях между приложением mVC ASP.NET и приложениями ASP.NET Web Forms. Узнайте, как решить, когда создавать ASP.NET приложение MVC.
Схема архитектуры Model-View-Controller (MVC) разделяет приложение на три основных компонента: модель, представление и контроллер. Платформа ASP.NET MVC является альтернативой шаблону ASP.NET Web Forms для создания веб-приложений на основе MVC. Платформа ASP.NET MVC является легковесной платформой отображения с широкими возможностями тестирования и, подобно приложениям на основе веб-форм, интегрирована с существующими функциями ASP.NET, например с главными страницами и проверкой подлинности на основе членства. Платформа MVC определена в пространстве имен System.Web.Mvc и является фундаментальной, поддерживаемой частью пространства имен System.Web.
MVC представляет собой стандартный шаблон разработки, знакомый многим специалистам. Некоторые типы веб-приложений имеют преимущества при создании на платформе MVC. Для других может быть целесообразно использование традиционной схемы приложения ASP.NET, основанной на веб-формах и обратной передаче. В некоторых случаях возможно сочетание двух подходов: применение одной схемы не исключает использования другой.
В состав платформы MVC входят следующие компоненты.
Рисунок 01: Ссылка на действие контроллера, которое ожидает значение параметра(Нажмите, чтобы просмотреть полноразмерное изображение)
В небольших приложениях эта модель подразумевает концептуальное, а не физическое разделение. Например, если приложение читает только набор данных и отправляет его в представление, приложение не имеет физического слоя модели и связанных классов. В этом случае набор данных берет на себя роль объекта модели.
Просмотры. Представления — это компоненты, отображающие пользовательский интерфейс приложения (UI). Пользовательский интерфейс обычно создается на основе данных модели. Примером может быть редактирование представления таблицы Продуктов, отображающая текстовые ящики, списки выпадающих и чековых коробок в зависимости от текущего состояния объекта продуктов.
Контроллеры. Контроллеры осуществляют взаимодействие с пользователем, работу с моделью, а также выбор представления, отображающего пользовательский интерфейс. В приложении MVC представление служит только для отображения информации. Обработку введенных данных, формирование ответа и взаимодействие с пользователем обеспечивает контроллер. Например, контроллер обрабатывает значения строки запроса и передает эти значения модели, что, в свою очередь, запрашивает базу данных с помощью значений.
Шаблон MVC позволяет создавать приложения, различные аспекты которых (логика ввода, бизнес-логика и логика интерфейса) разделены, но достаточно тесно взаимодействуют друг с другом. Эта схема указывает расположение каждого вида логики в приложении. Логика пользовательского интерфейса относится к представлению. Логика ввода относится к контроллеру. Бизнес-логика размещается в модели. Это разделение позволяет работать со сложными структурами при создании приложения, так как обеспечивает одновременную реализацию только одного аспекта. Например, разработчик может сконцентрироваться на создании представления отдельно от бизнес-логики.
В дополнение к упрощению сложных структур схема MVC также облегчает тестирование приложений по сравнению с веб-приложениями ASP.NET на основе веб-форм. Например, в веб-приложении ASP.NET на основе веб-форм один класс используется для отображения вывода и для ответа на ввод пользователя. Создание автоматических тестов для приложений ASP.NET на основе веб-форм может представлять сложности, так как для тестирования отдельной страницы следует создать экземпляр класса страницы, всех дочерних элементов управления и других зависимых классов приложения. Большое число экземпляров классов, необходимое для запуска страницы, усложняет создание тестов для отдельных частей приложения. Из-за этого тестирование приложений ASP.NET на основе веб-форм может быть сложнее тестирования приложения MVC. Более того, для тестирования приложения ASP.NET необходим веб-сервер. Платформа MVC разделяет компоненты и активно использует интерфейсы, что позволяет тестировать отдельные элементы вне остальной структуры.
Связь между основными компонентами приложения MVC также облегчает параллельную разработку. Например, один разработчик может работать над представлением, второй разработчик может работать над логикой контроллера, а третий — на бизнес-логике в модели.
Решение о создании приложения MVC
Следует внимательно продумать вопрос о создании веб-приложения на основе платформы ASP.NET MVC или на основе модели веб-форм ASP.NET. Платформа MVC не заменяет собой модель веб-форм. Обе модели можно использовать для веб-приложений. (при наличии существующих приложений на основе веб-форм они будут продолжать работу в нормальном режиме).
Перед использованием платформы MVC или модели веб-форм для определенного веб-сайта следует взвесить все преимущества каждого из подходов.
Преимущества веб-приложения на основе MVC
Платформа ASP.NET MVC имеет следующие преимущества.
Преимущества веб-приложения на основе веб-форм
Платформа на основе веб-форм имеет следующие преимущества.
Общие сведения ASP.NET Core MVC
Автор: Стив Смит (Steve Smith)
ASP.NET MVC является многофункциональной платформой для создания веб-приложений и API-интерфейсов с помощью структуры проектирования Model-View-Controller.
Шаблон MVC
Структура архитектуры MVC разделяет приложение на три основных группы компонентов: модели, представлении и контроллеры. Это позволяет реализовать принципы разделения задач. Согласно этой структуре запросы пользователей направляются в контроллер, который отвечает за работу с моделью для выполнения действий пользователей и (или) получение результатов запросов. Контроллер выбирает представление для отображения пользователю со всеми необходимыми данными модели.
На следующей схеме показаны три основных компонента и существующие между ними связи.
Такое распределение обязанностей позволяет масштабировать приложение в контексте сложности, так как проще писать код, выполнять отладку и тестирование компонента (модели, представления или контроллера) с одним заданием. Гораздо труднее обновлять, тестировать и отлаживать код, зависимости которого находятся в двух или трех этих областях. Например, логика пользовательского интерфейса, как правило, подвергается изменениям чаще, чем бизнес-логика. Если код представления и бизнес-логика объединены в один объект, содержащий бизнес-логику, объект необходимо изменять при каждом обновлении пользовательского интерфейса. Это часто приводит к возникновению ошибок и необходимости повторно тестировать бизнес-логику после каждого незначительного изменения пользовательского интерфейса.
Представление и контроллер зависят от модели. Однако сама модель не зависит ни от контроллера, ни от представления. Это является одним из ключевых преимуществ разделения. Такое разделение позволяет создавать и тестировать модели независимо от их визуального представления.
Функции модели
Модель в приложении MVC представляет состояние приложения и бизнес-логику или операций, которые должны в нем выполняться. Бизнес-логика должна быть включена в состав модели вместе с логикой реализации для сохранения состояния приложения. Как правило, строго типизированные представления используют типы ViewModel, предназначенные для хранения данных, отображаемых в этом представлении. Контроллер создает и заполняет эти экземпляры ViewModel из модели.
Функции представления
Функции контроллера
Контроллеры — это компоненты для управления взаимодействием с пользователем, работы с моделью и выбора представления для отображения. В приложении MVC представление служит только для отображения информации. Обработку введенных данных, формирование ответа и взаимодействие с пользователем обеспечивает контроллер. В структуре MVC контроллер является начальной отправной точкой и отвечает за выбор рабочих типов моделей и отображаемых представлений (именно этим объясняется его название — он контролирует, каким образом приложение отвечает на конкретный запрос).
Контроллеры не должны быть чересчур сложными из-за слишком большого количества обязанностей. Чтобы не перегружать логику контроллера, перенесите бизнес-логику из контроллера в модель предметной области.
Если ваш контроллер часто выполняет одни и те же виды действий, переместите эти действия в фильтры.
ASP.NET Core MVC
ASP.NET Core MVC представляет собой упрощенную, эффективно тестируемую платформу с открытым исходным кодом, оптимизированную для использования с ASP.NET Core.
ASP.NET Core MVC предоставляет основанный на шаблонах способ создания динамических веб-сайтов с четким разделением задач. Она обеспечивает полный контроль разметки, поддерживает согласованную с TDD разработку и использует новейшие веб-стандарты.
Маршрутизация
Платформа ASP.NET Core MVC создана на основе маршрутизации ASP.NET Core — мощного компонента сопоставления URL-адресов, который позволяет создавать приложения с понятными и поддерживающими поиск URL-адресами. Вы можете определять шаблоны именования URL-адресов приложения, эффективно работающие для оптимизации для поисковых систем (SEO) и для создания ссылок, независимо от способа организации файлов на веб-сервере. Вы можете определять маршруты с помощью понятного синтаксиса шаблонов маршрутов, который поддерживает ограничения значений маршрутов, значения по умолчанию и необязательные значения.
Маршрутизация на основе соглашений позволяет глобально определять форматы URL-адресов, которые принимает приложение, и то, как каждый из этих форматов соответствует конкретному методу действия на данном контроллере. При поступлении входящего запроса модуль маршрутизации выполняет синтаксический анализ URL-адреса и соотносит его с одним из определенных форматов URL-адресов, а затем вызывает метод действия связанного контроллера.
Маршрутизация атрибутов используется для указания сведений о маршрутизации путем добавления атрибутов, определяющих маршруты приложения, к контроллерам и действиям. Это означает, что определения маршрутов помещаются рядом с контроллером и действием, с которым они связаны.
Привязка модели
Привязка модели в ASP.NET Core MVC преобразует данные запроса клиента (значения форм, данные маршрута, параметры строки запроса, заголовки HTTP) в объекты, которые может обрабатывать контроллер. В результате логике контроллера не требуется определять данные входящего запроса — данные просто доступны в виде параметров для методов действий.
Проверка модели
ASP.NET MVC поддерживает возможность проверки, дополняя модель объекта атрибутами проверки заметок к данным. Атрибуты проверки проверяются на стороне клиента до размещения значений на сервере, а также на сервере перед выполнением действия контроллера.
Платформа обрабатывает проверку данных запроса на клиенте и на сервере. Логика проверки, указанная в типах модели, добавляется в готовые для просмотра представления в виде ненавязчивых заметок и реализуется в браузере с помощью подключаемого модуля jQuery Validation.
Внедрение зависимостей
ASP.NET Core имеет встроенную поддержку внедрения зависимостей (DI). В ASP.NET MVC Core контроллеры могут запрашивать необходимые служб через свои конструкторы, предоставляя им возможность следовать принципу явных зависимостей.
Кроме того, приложение может использовать внедрение зависимостей в файлы представления с помощью директивы @inject :
Фильтры
Фильтры помогают разработчикам решать общие задачи, такие как обработка исключений или авторизация. Фильтры активируют пользовательскую логику предварительной и завершающей обработки для методов действий и могут быть настроены для запуска в определенные моменты в конвейерном выполнении определенного запроса. Фильтры могут применяться к контроллерам или действиям в виде атрибутов (или могут выполняться глобально). В состав платформы входит несколько фильтров (например, Authorize ). [Authorize] является атрибутом, который используется для создания фильтров авторизации MVC.
Области
области позволяют секционировать крупные ASP.NET Core веб-приложения MVC в более мелкие функциональные группы. Область является структурой MVC внутри приложения. В проекте MVC логические компоненты, такие как модель, контроллер и представление, находятся в разных папках, и для создания связи между этими компонентами MVC использует соглашения об именовании. Крупное приложение может быть целесообразно разделить на отдельные высокоуровневые области функциональности. Например, приложение электронной коммерции с несколькими подразделениями, например извлечение, выставление счетов и поиск и т. д. Каждое из этих устройств имеет собственные представления логических компонентов, контроллеры и модели.
Веб-API
Помимо того, что ASP.NET Core MV прекрасно подходит для создания веб-сайтов, эта платформа располагает мощной поддержкой для построения веб-API. Создавайте службы, доступные для широкого круга клиентов, включая браузеры и мобильные устройства.
Платформа поддерживает согласования содержимого HTTP со встроенной поддержкой для форматирования данных в виде JSON или XML. Пишите пользовательские модули форматирования для добавления поддержки собственных форматов.
Используйте функции создания ссылок для поддержки гипермедиа. Легко включайте поддержку общего доступа к ресурсам независимо от источника (CORS) для совместного использования веб-API в нескольких веб-приложениях.
Тестирование
Благодаря используемым интерфейсам и внедрению зависимостей платформа хорошо подходит для модульного тестирования. Кроме того, с помощью таких компонентов, как TestHost и поставщик InMemory для Entity Framework, можно быстро и просто выполнять интеграционные тесты. Узнайте больше о тестировании логики контроллеров.
Razor Просмотреть подсистему
ASP.NET Core представления MVC используют Razor обработчик представлений для отображения представлений. Razor — Это компактный, выразительный и жидкий язык разметки шаблонов для определения представлений с помощью встраиваемого кода C#. Razor используется для динамического создания веб-содержимого на сервере. Серверный код можно полностью комбинировать с содержимым и кодом на стороне клиента.
С помощью Razor обработчика представлений можно определять макеты, частичные представления и заменяемые разделы.
Строго типизированные представления
Razor представления в MVC могут быть строго типизированы на основе модели. Контроллеры передают строго типизированную модель в представления для поддержки в них IntelliSense и проверки типов.
Например, следующее представление отображает модель типа IEnumerable
Вспомогательные функции тегов
Вспомогательные функции тегов позволяют коду на стороне сервера принимать участие в создании и ОТРИСОВКЕ HTML-элементов в Razor файлах. Вспомогательные функции тегов используются для определения настраиваемых тегов (например, ) или для изменения поведения существующих тегов (например, ). Вспомогательные функции тегов привязываются к определенным элементам на основе имени элемента и его атрибутов. Они предоставляют преимущества отрисовки на стороне сервера, сохраняя при этом возможности редактирования HTML.
Существует множество встроенных вспомогательных функций тегов для общих задач — например, для создания форм, ссылок, загрузки ресурсов и т. д. Кроме того, огромное количество функций доступно в общедоступных репозиториях GitHub и в качестве пакетов NuGet. Вспомогательные функции тегов разрабатываются на C# и предназначены для HTML-элементов на основе имени элемента, имени атрибута или родительского тега. Например, встроенную функцию LinkTagHelper можно использовать для создания ссылки на действие AccountsController для Login :
С помощью EnvironmentTagHelper можно включать в приложения различные сценарии (например, необработанные или минифицированные) для конкретной среды выполнения (разработки, промежуточной или производственной):
Вспомогательные функции тегов обеспечивают удобный для HTML процесс разработки и расширенную среду IntelliSense для создания HTML и Razor разметки. Большинство встроенных вспомогательных функций тегов работают с существующими HTML-элементами и предоставляют для них атрибуты на стороне сервера.
Компоненты представлений
Компоненты представлений позволяют упаковывать логику отрисовки и повторно использовать ее в приложении. Они аналогичны частичным представлениям, но имеют связанную логику.
MVC Framework: большое введение для начинающих
Необходимое отступление: не так давно я разместил статью предназначавшуюся для печатного издания. Приведенная ниже статья имеет ту же самую судьбу: она не попала в печать в связи с тяжелым положением журнала. Как и в прошлый раз, я решил опубликовать статью на Хабре, благо тематика попадает под формат. Необходимо заметить, что статья оформлена и содержит текст для журнала, если бы она готовилась для Хабра, то некоторые часть могли бы быть изменены. Надеюсь, статья вам понравится.
O MVC
Паттерн Модель-представление-контроллер или по-английски Model-view-controller используется очень давно. Еще в 1979 году его описал Тригве Реенскауг в своей работе «Разработка приложений на Smalltalk-80: как использовать Модель-представление-контроллер». С тех пор паттерн зарекомендовал себя как очень удачная архитектура программного обеспечения.
Пользователь, работая с интерфейсом, управляет контроллером, который перехватывает действия пользователя. Далее контроллер уведомляет модель о действиях пользователя, тем самым изменяя состояние модели. Контроллер также уведомляет представление. Представление, используя текущее состояние модели, строит пользовательский интерфейс.
Основой паттерна является отделение модели данных приложения, его логики и представления данных друг от друга. Таким образом, следуя правилу «разделяй и властвуй», удается строить стройное программное обеспечение, в котором, во-первых, модель не зависит от представления и логики, а во-вторых, пользовательский интерфейс надежно отделен от управляющей логики.
ASP.NET MVC Framework
С другой стороны, MVC Framework не предполагает использование классических web-форм и web-элементов управления, в нем отсутствуют такие механизмы как обратные вызовы (postbacks) и состояние представления (viewstate). MVC Framework так же предлагает использование URL-mapping и архитектуру REST в качестве модели запросов, что положительно повлияет на поисковую оптимизацию web-проектов.
— | Классический ASP.NET | MVC |
Модель запросов | postback | REST |
Модель данных | через код cs-файла страницы (code-behind) | определяется паттерном MVC |
Разработка интерфейса | web-controls | чистый html, MVC UI Helpers |
Авто-генерация id | да | нет |
ViewState | есть | нет |
URL mapping | нет | есть |
В целом, высказывая свое мнение, я могу сказать, что MVC Framework предложил для разработчиков ASP.NET новый стиль, ориентированный на качество клиентского кода. Генерируемый MVC код страниц не содержит ничего автоматически создаваемого, здесь нет раздутых идентификаторов, нет огромных viewstate, написание клиентских скриптов упрощено в связи с тем, что код страницы представляет собой чистый, созданный самим программистом HTML. В эпоху, когда понятие web 2.0 прочно вошло в нашу жизнь полный контроль над страницей на клиентской стороне – это залог успеха любого web-проекта.
Версии MVC Framework
Советы
Как задать на странице html-элемент select
var products = GetProducts();
ViewData[«sampleSelect»] = new SelectList(products, «Id», «Name»);
Где
GetProducts – это некий метод, источник данных в виде IEnumerable, такие источники данных следует располагать в модели данных, здесь приведено упрощенно для примера;
SelectList – это вспомогательный класс определенный в System.Web.MVC.
Здесь, через ViewData передается набор данных созданных с помощью класса SelectList, конструктор которого через первый параметр принимает данные в виде products. Имена свойств, определенных в классе Product, для значений и выводимого текста в select передается вторым и третьим параметрами.
Как отобразить пользовательский элемент управления
Для того чтобы отобразить свой элемент управления используется представленный в preview 5 метод Html.RenderPartial(. ). Для того чтобы использовать пользовательский элемент управления в своих проектах он должен быть создан как MVC View User Control, а не как обычный Web User Control. Разница заключается в том, от какого класса наследуется созданный элемент. В случае MVC, элемент будет наследоваться от System.Web.Mvc.ViewUserControl.
Вывод пользовательского элемента не составляет труда:
Где SampleUserCtrl – это имя класса, который представляет пользовательский элемент управления.
Как присвоить элементу, созданному через класс Html, атрибут class
Когда мало ViewData
Разделяем логику GET и POST запросов
[AcceptVerbs( «GET» )]
public ActionResult Login()
<
return View( «Index» );
>
Управление кэшированием
MVC Framework позволяет управлять кэшированием результата каждого action. То есть, вы можете задать каким образом и сколько будет кэшироваться тот или иной запрос на сервере или на клиенте. Для этого существует аналог директивы классического asp.net атрибут [OutputCache]. Ниже перечислены его параметры:
Параметр | Описание |
VaryByHeader | строка с разделенными через точку с запятой значениями http-заголовков по которым будет производиться условное кэширование |
VaryByParam | задает условное кэширование основанное на значениях строки запроса при GET или параметров при POST |
VaryByContentEncoding | указывает условие кэширование в зависимости от содержимого директивы http-заголовка Accept-Encoding |
Duration | Duration задает значение времени в секундах, в течение которого страница или пользовательский элемент кэшируются |
NoStore | принимает булево значение. Если значение равно true, то добавляет в директиву http-заголовка Cache-Control параметр no-store |
CacheProfile | используется для указания профиля кэширования заданного через web.config и секцию caching |
OutputCacheLocation | этот параметр описывает правило для места хранения кэша и принимает одно из значений перечисления OutputCacheLocation |
VaryByCustom | любой текст для управление кэшированием. Если этот текст равен «browser», то кэширование будет производиться условно по имени браузера и его версии (major version). Если у VaryByCustom будет указана строка, то вы обязаны переопределить метод GetVaryByCustomString в файле Global.asax для осуществления условного кэширования. |
Использование OutputCache очень элементарное. Следующий пример показывает, как кэшировать результат action Index на 10 секунд.
Сложные страницы и пользовательские модели
Зачастую в создании страниц участвует множество самых разнородных данных. Скажем, на персональной странице пользователя какого-либо портала могут быть данные с его избранными новостями, данные его профиля, данные о сообщениях посланных ему другими участниками, данные о погоде или дата и точное время, и еще масса разных данных.
Такие данные при хранении в базах данных хранятся не в одной таблице, а в нескольких, может даже в нескольких десятках. В таком случае, если вы используете ОRM – объектную модель базы данных, то для создания одной страницы MVC Framework вам придется инициализировать множество списочных или других переменных и заполнить их данными.
Я рекомендую в таком случае сделать свою комплексную модель данных, реализовав букву M из слова MVC. Ниже я приведу пример одного из вариантов реализации такой модели:
public class BankInfoModel
<
public Bank Bank;
public IEnumerable BankBranches;
>
Создается модель, которая содержит значение Bank и перечисление всех отделений этого банка (допустим, по ряду причин, мы не можем получить список отделений просто через Bank).
Для прозрачного использования нашей модели мы должны сделать следующее: переделать базовый класс нашего представления с
public partial class Index: ViewPage
public partial class Index : ViewPage
Теперь, в коде представления, нам доступен инстанцированный экземпляр модели типа BankInfoModel через ViewData.Model. Конечно, контроллер должен его инициализировать для нас, но это элементарно:
Где int? id – это параметр, который указывает на идентификатор банка
Использование экземпляра нашей модели в представлении также просто:
div class =»vcard» >
h1 > span class =»fn org» > =ViewData.Model.Bank.shortName %> span > h1 >
p > Телефон: span class =»fn phone» > =ViewData.Model.Bank.phone %> span > p >
div >
Сложные типы, ModelBinder
[AcceptVerbs(«POST»)]
public ActionResult Login(string userLogin, string userPass)
public class LoginModel
<
public string userLogin < get ; set ; >
public string userPass
public class LoginModelBinder : IModelBinder
<
public object GetValue(ControllerContext controllerContext, string modelName,
Type modelType, ModelStateDictionary modelState)
Обратите внимание, мы определяем метод GetValue и заполняем в нем данные модели через контекст запроса.
Перед заключительным шагом нам необходимо указать для нашего класса модели LoginModel атрибут ModelBinder:
[ModelBinder( typeof (LoginModelBinder))]
public class LoginModel
<
public string userLogin < get ; set ; >
public string userPass
[AcceptVerbs(«POST»)]
public ActionResult Login([ModelBinder(typeof(LoginModelBinder))] LoginModel loginModelData)
[AcceptVerbs(HttpVerbs.Post)]
public ActionResult Login(LoginModel loginModelData)
[AcceptVerbs(HttpVerbs.Post)]
public ActionResult Login([Bind(Prefix=””, Include=”userLogin, userPass”)] LoginModel loginModelData)
И хотя мы не обязаны создавать свои варианты ModelBinder этот инструмент все же может пригодиться и будет полезным для тонкой настройки обработки значений комплексных типов переданных с формы.
Перехват необработанных ошибок, неверных URL
Известно, что ничего так не сбивает с толку пользователя как непонятная ошибка, возникшая на ровном месте. Даже, если в вашем проекте такие ошибки время от времени происходят, необходимо позаботится о том, чтобы пользователь получал уведомление как можно более дружелюбно. Для таких целее используются страницы ошибок, перехват необработанных исключений, а так же обработка 404 ошибки http «Страница не найдена».
Для перехвата необработанных исключений необходимо создать в папке Views/Shared страницу Error.aspx с информацией об ошибке, которая содержит, например, такой код:
span >
Ой! Извините, но на нашей странице произошла ошибка. br />
Текст ошибки: = ViewData.Model.Exception.Message %>
span >
[HandleError]
public class HomeController: Controller
public class ErrorController : Controller
<
public ActionResult Index()
<
return RedirectToAction( «Http404» );
>
public ActionResult Http404()
<
Response.StatusCode = 404;
return View();
>
>
h1 > 404 h1 >
p > Запрошенной страницы не существует p >
customErrors mode =»RemoteOnly» >
error statusCode =»404″ redirect =»
Таким образом, все наши пользовательские исключения типа 404 будут также перенаправляться на нашу страницу Http404.aspx, что позволит сохранить общий подход и объединить под понятие «ненайденной страницы» как неверные URL, так и URL-введенные с ошибкой или в силу каких-то других причин неприемлемые для обработки, например из-за нарушения прав доступа.
Следует учесть, что для правильно работы перехвата ошибок в IIS7 требуется выставить следующие параметры в разделе «Страницы ошибок» настроек вашего сайта.
Заключение
В статье я попытался описать некоторые аспекты работы с MVC Framework. Многие моменты – элементарны, некоторые не так просты, как кажутся, часть – хорошо описана в интернете, часть – не описана вовсе. Во всех случаях приведенный материал может сослужить хорошую службу как начинающим знакомство с MVC Framework, так и тем, кто уже имеет опыт создания web-приложений с его помощью.
MVC Framework сегодня – это, всего лишь, бета-версия того продукта, который будет в итоге. Но уже сейчас этот инструмент позволяет создавать web-приложения, используя все мощь паттерна MVC. Возможно, когда вы будете читать эту статью, выйдет финальный релиз MVC Framework, который ожидается к концу 2008 года, но можно предположить, что большинство функций уже не будет изменено.