- •Роль инкапсуляции
- •Роль наследования
- •Роль полиморфизма
- •Конструкторы
- •Конструктор копирования
- •Деструкторы
- •Перегрузка методов
- •Перегрузка операторов
- •Перегрузка бинарных операторов
- •Перегрузка унарных операторов
- •Выполнение операций со встроенными в с# типами данных
- •Переопределение методов Перекрытие методов
- •Сокрытие методов
- •Вызов базовых версий методов
- •Область видимости переменных
- •Конфликты областей видимости локальных переменных
- •Конфликты областей видимости полей и локальных переменных
- •Константы
- •Модификаторы доступа
- •Пространства имен
- •Uml. Диаграмма вариантов использования. Привести пример.
- •Чтение схем вариантов использования
- •Субъекты, варианты использования и подсистемы
- •Структурирование вариантов использования
- •Количество элементов между субъектами и вариантами использования
- •Задание количества элементов в ассоциации
- •Uml. Диаграмма классов. Привести пример.
- •Типы атрибутов и операций
- •Несколько типов
- •Атрибуты и ассоциации
- •Обобщение
- •Реализация
- •Uml. Диаграмма последовательности. Привести пример.
- •Создание схемы последовательностей
- •Изменение порядка сообщений
- •Перемещение или копирование последовательностей сообщений на схеме последовательностей
- •Оптимизация размещения элементов на схеме последовательностей
- •Изменить пакет, владеющий взаимодействием
- •Типы сообщений
- •Создание заметок о взаимодействиях
- •Инициирующее событие
- •Уровень детализации
- •Uml. Диаграмма деятельности. Привести пример. Простые потоки управления
- •Параллельные потоки
- •Потоки данных
- •Основные этапы создания схем активности
- •Uml. Диаграмма кооперации. Привести пример.
- •Uml. Диаграмма состояний. Привести пример.
- •Понятие состояния объекта
- •Переход
- •Сложные переходы
- •Переходы между параллельными состояниями
- •Переходы между составными состояниями
- •Синхронизирующие состояния
- •Uml. Диаграмма компонентов. Диаграмма развертывания. Привести пример.
- •Структурный паттерн проектирования «Компоновщик». Привести пример.
- •Структурный паттерн проектирования «Оболочка». Привести пример.
- •Структурный паттерн проектирования «Мост». Привести пример.
- •Структурный паттерн проектирования «Адаптер». Привести пример.
- •Структурный паттерн проектирования «Заместитель». Привести пример.
- •Структурный паттерн проектирования «Приспособленец». Привести пример.
- •Поведенческий паттерн проектирования «Команда». Привести пример.
- •Поведенческий паттерн проектирования «Наблюдатель». Привести пример.
- •Поведенческий паттерн проектирования «Состояние». Привести пример.
- •Поведенческий паттерн проектирования «Итератор». Привести пример.
- •Поведенческий паттерн проектирования «Цепочка обязанностей». Привести пример.
- •Поведенческий паттерн проектирования «Шаблонный метод». Привести пример.
- •Порождающий паттерн проектирования «Абстрактная фабрика». Привести пример.
- •Порождающий паттерн проектирования «Абстрактный метод». Привести пример.
- •Порождающий паттерн проектирования «Одиночка». Привести пример.
- •Порождающий паттерн проектирования «Прототип». Привести пример.
- •Порождающий паттерн проектирования «Строитель». Привести пример
- •Архитектурный шаблон проектирование mvc. Привести пример. Введение
- •«Оригинальный» mvc
- •Model (Модель)
- •View (Представление)
- •Controller (Контроллер)
- •Недостатки mvc и Document-View
- •Почему интерфейс?
- •Отличия от mvc
- •Заключение
Архитектурный шаблон проектирование mvc. Привести пример. Введение
В наше время сложно найти разработчика, который не слышал бы о паттерне под названием Model-View-Controller или сокращенно MVC, что вообщем не удивительно, с задачей отделения данных от их представления сталкиваешься практически на каждом проекте. Однако, как ни странно, столь же сложно найти разработчика, который действительно четко себе представляет, что такое на самом деле паттерн MVC и как его можно реализовать в конкретной ситуации. Подобное неведение явилось следствием того, что по историческим причинам данной аббревиатурой принято называть не один единственный паттерн, а целое семейство паттернов, призванное отделять представление от модели. Произошло это в силу разных обстоятельств. Отчасти из-за того что MVC не просто паттерн, а довольно объемное архитектурное решение, в котором каждый новый разработчик видел что-то свое и ставя во главу угла особенности своего проекта, реализовывал его по своему. Отчасти же из-за возраста данного паттерна, во времена его изобретения и сами приложения, и графические интерфейсы были существенно беднее чем в наше время, с тех пор они сильно эволюционировали и вместе с ними изменялся и сам паттерн. Данная статья посвящена также одному из паттернов входящих в это семейство, причинам его появления, особенностям применения, преимуществам и недостаткам, а так же описанию сопутствующих паттернов.
«Оригинальный» mvc
Несмотря на то, что, как уже говорилось, под аббревиатурой MVC обычно понимают целое семейство паттернов, можно выделить первоначальный вариант данного архитектурного решения. На данный момент, применение MVC в оригинальном виде вряд ли будет оправдано, по разным причинам, однако эволюцию паттерна лучше проследить с самого начала...
Впервые паттерн MVC появился в языке SmallTalk в конце семидесятых. Собственно задача была хорошо всем знакомая, надо было придумать архитектурное решение, которое позволяло бы манипулировать графическими представлениями данных некоего приложения, таким образом, чтобы изменение Представления этих данных не влияло на бизнес-логику и данные (Модель) приложения, а так же, чтобы была возможность иметь несколько Представлений для одной Модели. Таким решением и стал паттерн MVC, идея которого родилась в недрах Xerox PARK, и получила свое первое публичное упоминание в документации к SmallTalk’80. В классическом варианте, MVC состоит из трех частей, которые и дали ему название.
Model (Модель)
Под Моделью, обычно понимается часть содержащая в себе функциональную логику приложения, иными словами то, что мы обычно называем «Business Layer», «Бизнес-слой» или «Слой бизнес логики». Как именно организован этот слой, по большому счету не важно, однако есть ряд ключевых моментов, на которых мы остановимся позднее. Основная цель паттерна - сделать так, чтобы Модель была полностью независима от остальных частей и практически ничего не знала об их существовании, что позволило бы менять и Контроллер и Представление модели, не трогая саму Модель и даже позволить функционирование нескольких экземпляров Представлений и Контроллеров с одной Моделью одновременно. Вследствии чего, Модель ни при каких условиях не может содержать ссылок на объекты Представления или Контроллера.
Обычно различают несколько типов паттернов в зависимости от роли модели.
Passive Model (пассивная модель) - Модель не имеет вообще никаких способов воздействовать на Представление или Контроллер и только используется ими в качестве источника данных для отображения. Все изменения модели отслеживаются Контроллером и он же отвечает за перерисовку Представления, если это необходимо.
Active Model (активная модель) - Модель имеет возможность оповестить Представление о том, что в ней произошли некие изменения, и Представление может эти изменения отобразить. Как правило, механизм оповещения реализуется на основе паттерна Observer (обозреватель), Модель просто бросает сообщение, а Представления, которые заинтересованы в оповещении, подписываются на эти сообщения, что позволяет сохранить независимость Модели как от Контроллера так и от Представления, не нарушая тем самым основного свойства паттерна. Классической реализацией паттерна MVC принято считать версию именно с активной Моделью.
СОВЕТ Паттерн Observer (Обозреватель), известен так же под именем Publish/Subscribe (Публикатор/Подписчик), предназначен для организации наблюдения за состоянием объекта. Суть паттерна в том, что несколько объектов, называемых «обозревателями» или «слушателями» (listeners), регистрируются, сами или с чьей-либо помощью, в качестве обработчиков события (event), которое инициируется наблюдаемым объектом – «субъектом» (Subject) при изменении своего состояния. Таким образом достигается независимость «Субъекта» от «Обозревателей». Более подробно с паттерном можно ознакомится здесь: http://en.wikipedia.org/wiki/Observer_pattern и здесь: http://dofactory.com/Patterns/PatternObserver.aspx |