Контроллеры

Model-View-Controller

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

Реализация в ASP.NET будет выглядит следующим образом (пример взят с MSDN ). Представление – это обычная aspx разметка:

Модель – отдельный класс, у которого есть методы получения данных (модель в реализациях часто включает в себя так же и Data Access Level):

Пример модели не самый удачный в данном случае, но все-таки не всегда бывает необходимость иметь действительно описанную бизнес модель в классах, иногда хватает и работы с DataSet’ами. Самое интересное, это реализация контроллера, по сути это code behind aspx страницы.

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

Коротко о паттерне MVC

Как следует из названия, паттерн MVC включает в себя 3 компонента: Модель, Представление и Контроллер. Каждый из компонентов выполняет свою роль и является взаимозаменяемым. Это значит, что компоненты связаны друг с другом лишь некими четкими интерфейсами, за которыми может лежать любая реализация. Такой подход позволяет подменять и комбинировать различные компоненты, обеспечивая необходимую логику работы или внешний вид приложения. Разберемся с теми функциями, которые выполняет каждый компонент.

Модель

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

Например, для одного приложения мы можем создать несколько моделей. Одна будет отладочной, а другая рабочей. Первая может хранить свои данные в памяти или в файле, а вторая уже задействует базу данных. По сути это просто паттерн Стратегия.

Представление

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

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

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

Контроллер

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

Фактически на каждое действие, которое может сделать пользователь в Представлении, должен быть определен обработчик в Контроллере. Этот обработчик выполнит соответствующие манипуляции над моделью и в случае необходимости сообщит Представлению о наличии изменений.

A Simple Implementation of MVC using Java

We will have the following three:

1. 1. StudentObject : the model.

1. 1. StudentView: view class to print details on the console.

1. StudentController: a controller that stores data in studentObject and updates StudentView accordingly

Step 1: Create the Model

public class Student {
private String rollNo;
private String name;

public String getRollNo() {
return rollNo;
}

public void setRollNo(String rollNo) {
this.rollNo = rollNo;
}

public String getName() {
return name;
}

public void setName(String name) {
this.name = name;
}
}

The code is self-explanatory. It consists of functions to get/set roll number and names of the students. Let’s call it “student.java”.Step 2: Create the View

public class StudentView {
public void printStudentDetails(String studentName, String studentRollNo){
System.out.println("Student: ");
System.out.println("Name: " + studentName);
System.out.println("Roll No: " + studentRollNo);
}
}

This is simply to print the values to the console. Let’s call this “studentView.java”.Step 3: Create the Controller

public class StudentController {
private Student model;
private StudentView view;
public StudentController(Student model, StudentView view){
this.model = model;
this.view = view;
}
public void setStudentName(String name){
      model.setName(name);
}
public String getStudentName(){
return model.getName();
}
public void setStudentRollNo(String rollNo){
      model.setRollNo(rollNo);
}
public String getStudentRollNo(){
return model.getRollNo();
}
public void updateView(){
      view.printStudentDetails(model.getName(), model.getRollNo());
}
}

Call this “StudentController.java”. A cursory glance will tell you that this controller is just responsible for calling the model to get/set the data, and then updating the view. Now, let’s have a look at how all of this is tied together.Step 4: Create the main Java file

public class MVCPatternDemo {
public static void main(String[] args) {
//fetch student record based on his roll no from the database
Student model  = retriveStudentFromDatabase();
//Create a view : to write student details on console
StudentView view = new StudentView();
StudentController controller = new StudentController(model, view);
      controller.updateView();
//update model data
      controller.setStudentName("John");
      controller.updateView();
}
private static Student retriveStudentFromDatabase(){
Student student = new Student();
      student.setName("Robert");
      student.setRollNo("10");
return student;
}
}

This is called “MVCPatternDemo.java”. As you can see, it fetches the student data from the database or a function (in this case we’re using a function to set the values) and pushes it on to the Student model. Then, it initialises the view we had created earlier. Further, it also initialises our controller and binds it to the model and the view. The updateView() method is a part of the controller which updates the student details on the console. Step 5: Test the ResultIf everything goes right, the result should be:

Student: 
Name: Robert
Roll No: 10
Student: 
Name: John
Roll No: 10

If you get this as the output, congratulations! You’ve successfully implemented the MVC architecture using Java, albeit for a simple application. However simple, this application is enough to demonstrate the powers of the MVC architecture. 15 Must-Know Spring MVC Interview Questions

Wrapping Up…After so much said and done, it’s hard to emphasise more on the power of the MVC architecture in any web/desktop application these days. It provides an altogether new level of modularity to your code which makes it a lot more readable and maintainable. So, if you want to scale to new heights in your career as an application developer, getting hold of the MVC architecture and its working should be your top priority. Do drop by a comment and let us know how you like this article!

What exactly is the MVC architecture?

Before we get into the technicalities of it, let’s make some things clear – MVC is NOT a design pattern, it’s a way to structure your applications. In recent years, the web applications are extensively using the MVC architecture, and hence it’s natural to confuse it for a design pattern exclusive for web applications. However, let’s tell you that MVC was first described way back in 1979 – before the WWW era when there was no concept of web applications. The architecture used today for web applications is an adaptation of the original pattern.In fact, this architecture was initially included in the two major web development frameworks – Struts and Ruby on Rails. These two environments paved the way for a majority of web frameworks that came later – and thus the popularity of this architecture kept rising.

MVC architectural pattern follows an elementary idea – we must separate the responsibilities in any application on the following basis:

• Model: Handles data and business logic.
• View: Presents the data to the user whenever asked for.
• Controller: Entertains user requests and fetch necessary resources.

Each of the components has a demarcated set of tasks which ensures smooth functioning of the entire application along with complete modularity. Let us have a look at each of these components in further detail.

Controller

The controller is the like the housekeeper of the application – it performs coordination between model and view to entertain a user request. The user requests are received as HTTP get or post request – for example, when the user clicks on any GUI elements to perform any action.The primary function of a controller is to call and coordinate with the model to fetch any necessary resources required to act. Usually, on receiving a user request, the controller calls the appropriate model for the task at hand.

View

As the name suggests, the view is responsible for rendering the data received from the model. There may be pre-designed templates where you can fit the data, and there may even be several different views per model depending on the requirements.

Any web application is structured keeping these three core components in mind. There may be a primary controller that is responsible for receiving all the requests and calling the specific controller for specific actions. Let’s understand the working of a web application under the MVC architecture better using an example.

Let’s See an Example

Let’s take an example of an online stationery shop. The user can view items, buy, add items to cart, add items to current order, or even add/remove items (if he’s the admin).Now, let’s see what will happen when a user clicks on the title “Pens” to see the list of pens.Our application will have a particular controller to handle all the queries related to pens. Let’s say it’s called “pens_controller.php”. We’ll also have a model that will store the data regarding the pens we have – let’s call it “pens_model.php”. Finally, we’ll have several views to present the data – a list of pens, a table displaying pens, a page to edit the list, etc.The following figure shows the complete flow of control right from the moment a user clicks on “pens”, to when the result is rendered in front of him:First, the “pens_controller.php” handles the user request (1) as a GET or POST request. We can also have an “index.php” which is the central controller which will call the “pens_controller” whenever needed.The controller then examines the request and the parameters and calls the required model – in this case, “pens_model.php”. The controller asks the model to return the list of available pens (2).Now, the model searches the database for the necessary information (3), applies logics if necessary, and returns the data to the controller(4).The controller then picks an appropriate view (5) and presents the data (6 and 7). If a request comes from a handheld device, a view suitable for it will be used, or if the user has a particular theme selected, its view will be picked – and so on. How to Become a Full Stack Developer

Model-View-Controller

При разделении системы на модель и представление, остается неопределенным кто должен обрабатывать действия пользователя. Очевидно, измениться должна модель, но ведь пользователь видит и может взаимодействовать лишь с элементами представления… Решением проблемы является создание посредника (шаблон проектирования Mediator), который в контексте MVC называется контроллером и занимается обработкой действий пользователя .

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

Диаграмма последовательности шаблона model-view-controller

Контроллер часто содержит достаточно небольшое количество логики, поэтому нередко его обязанности перекладывают на Представление — в этом случае, говорят что используется шаблон проектирования Document-View. Однако, это нарушает принцип единой ответственности (Single Responsibility Principle), а значит приводит к последствиям, перечисленным в начале статьи.

Исходный код более простого примера:

#include <iostream>
#include <string>
#include <vector>
using namespace std;

struct Food {
    int value;
};

struct Animal {
    void feed(Food& food) {
        int eat_value = std::min(max_repletion-repletion, food.value);
        repletion += eat_value;
        food.value -= eat_value;

        cout << "feeds: " << name << endl;
    }
    void step() {
        if (repletion > 0)
            repletion--;
    }
    virtual ~Animal() = default;
    Animal(int _repletion, int _max_repletion, string _name)
        : repletion(_repletion), max_repletion(_max_repletion), name(_name) {
    }
protected:
    int repletion;
    int max_repletion;
    string name;
};

struct Cat : public Animal {
    Cat(string _name, int _repletion) : Animal(_repletion, 10, _name) {
    }
};

struct Dog : public Animal {
    Dog(string _name, int _repletion) : Animal(_repletion, 20, _name) {
    }
};

struct Bowl {
    Bowl(int value) {
        food.value = value;
    }
    void subscribe(Animal* animal) {
        animals.push_back(animal);
    }
    void add(int value) {
        cout << "add " << value << " in bowl" << endl;
        food.value += value;
        for (auto animal : animals) {
            if (food.value == 0) {
                break;
            }
            animal->feed(food);
        }
    }
protected:
    Food food;
    vector<Animal*> animals;
};


int main() {
    Cat cat_a("murzik", 1);
    Cat cat_b("matroskin", 5);
    Dog dog_c("sharik", 2);

    Bowl bowl(0);

    bowl.add(5);

    bowl.subscribe(&cat_a);
    bowl.subscribe(&cat_b);
    bowl.subscribe(&dog_c);

    bowl.add(5);
    bowl.add(30);
}

MVVM

MVVMдаModel-View-ViewModelСокращение для. MicrosoftWPF (Windows Presentation Foundation — среда пользовательского интерфейса Microsoft на базе Windows)Приносит новый технический опыт, делая уровень пользовательского интерфейса программного обеспечения более детализированным и настраиваемым. В то же время на техническом уровне WPF также предоставляетПривязка (привязка), свойство зависимости (свойство зависимости), перенаправленные события (перенаправленные события), команда (команда), DataTemplate (шаблон данных), ControlTemplate (шаблон элемента управления)И другие новые функции.Режим MVVM на самом деле представляет собой новый тип архитектурного режима, разработанный, когда режим MV объединяется с WPF. Он основан на исходной платформе MVP и включает новые функции WPF для удовлетворения все более сложных потребностей клиентов.

Идея дизайна MVVM: обратите внимание на изменения модели и позвольте платформе MVVM автоматически обновлять состояние DOM, тем самым освобождая разработчиков от утомительных шагов по эксплуатации DOM

В чем разница между mvvm и mvc?

Разница между mvc и mvvm не такая уж большая. Это дизайнерская идея. В основном контроллер в mvc превратился в viewModel в mvvm. mvvm в основном решает проблему, заключающуюся в том, что большое количество операций DOM в mvc снижает производительность рендеринга страницы, снижает скорость загрузки и влияет на взаимодействие с пользователем. А когда Модель часто меняется, разработчикам необходимо активно обновляться до View.

В рамках MVVM представление и модель не могут взаимодействовать напрямую. Они могут взаимодействовать только через ViewModel. Он может отслеживать изменения в данных, а затем уведомлять представление об автоматическом обновлении, а когда пользователь манипулирует представлением, виртуальная машина также может отслеживать изменения в представлении. , А затем уведомить данные о внесении соответствующих изменений, что фактически обеспечивает двустороннюю привязку данных. И V и VM могут общаться.

Преимущества MVVM:

Режим MVVM аналогичен режиму MVC,Основное назначение — разделить вид (View) и модель (Model)., Имеет ряд преимуществ:

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

2. Возможность повторного использования, Вы можете поместить некоторую логику представления в ViewModel, позволить многим представлениям повторно использовать эту логику представления.

3. Самостоятельное развитие, Разработчики могут сосредоточиться на бизнес-логике и разработке данных (ViewModel), дизайнеры могут сосредоточиться на дизайне страниц, с помощью Expression Blend можно легко проектировать интерфейсы и генерировать XML-код.

4. ПроверяемыйИнтерфейс всегда было сложно тестировать, но теперь тест можно написать для ViewModel.

The parts of MVC

Model: Model code typically reflects real-world things. This code can hold raw data, or it will define the essential components of your app. For instance, if you were building a To-do app, the model code would define what a “task” is and what a “list” is – since those are the main components of a todo app.
View: View code is made up of all the functions that directly interact with the user. This is the code that makes your app look nice, and otherwise defines how your user sees and interacts with it.
Controller: Controller code acts as a liaison between the Model and the View, receiving user input and deciding what to do with it. It’s the brains of the application, and ties together the model and the view.

The Advantages of the MVC Architecture

A common problem faced by application developers these days is the support for different type of devices. The MVC architecture solves this problem as developers can create different interfaces for different devices, and based on from which device the request is made, the controller will select an appropriate view. The model sends the same data irrespective of the device being used, which ensures a complete consistency across all devices.The MVC separation beautifully isolates the view from the business logic. It also reduces complexities in designing large application by keeping the code and workflow structured. This makes the overall code much easier to maintain, test, debug, and reuse.

UML-диаграммы игры Сапер

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

Диаграмма Состояний игровой клетки

Любая клетка на игровом поле может находиться в одном из 4 состояний:

1. Клетка закрыта;
2. Клетка открыта;
3. Клетка помечена флажком;
4. Клетка помечена вопросительным знаком.

Здесь мы определили лишь состояния, значимые для Представления. Поскольку мины в процессе игры не отображаются, то и в базовом наборе соответствующего состояния не предусмотрено. Определим возможные переходы из одного состояния клетки в другое с помощью UML Диаграммы Состояний:

Диаграмма Классов игры Сапер

Поскольку мы решили создавать наше приложение на основе паттерна MVC, то у нас будет три основных класса: , и , а также вспомогательный класс для хранения состояния клетки. Рассмотрим их диаграмму классов:

Организация архитектуры довольно проста. Здесь мы просто распределили задачи по каждому классу в соответствии с принципами паттерна MVC:

1. В самом низу иерархии расположен класс игровой клетки . Он хранит позицию клетки, определяемую рядом и столбцом игрового поля; одно из состояний , которые мы описали в предыдущем подразделе; информацию о наличии мины в клетке () и счетчик мин в соседних клетках . Кроме того, у него есть два метода: для циклического перехода по состояниям, связанным с пометками, появляющимися в результате щелчка правой кнопкой мыши, а также , который обрабатывает событие, связанное с щелчком левой кнопкой мыши;
2. Чуть выше расположен класс Модели . Он является контейнером для игровых клеток . Его первый метод подготавливает игровое поле для начала игры. Метод делает проверку игрового поля на состояние выигрыша и возвращает истину, если игрок победил, иначе возвращается ложь. Для проверки проигрыша предназначен аналогичный метод . Методы и всего лишь делегируют действия соответствующим клеткам на игровом поле, а метод возвращает запрашиваемую игровую клетку;
3. Класс Представления включает следующие методы: — обеспечивает перерисовку Представления для отображения актуального состояния игрового поля в Модели; — возвращает настройки игры, заданные пользователем; — создает игровое поле на основе данных Модели; и соответственно отображают сообщения о победе и проигрыше;
4. И наконец класс Контроллера . В нем определено всего три метода на каждое возможное действие игрока: отвечает за нажатие на кнопке «Новая игра» в интерфейсе Представления; и обрабатывают щелчки по игровым клеткам левой и правой кнопками мыши соответственно.

Понятие привязки моделей

Привязка моделей представляет собой элегантный мост между HTTP-запросом и методами C#, определяющими действия. Большинство приложений ASP.NET MVC Framework в той или иной степени полагаются на привязку моделей, в том числе простой пример приложения, созданный в предыдущем разделе. Чтобы увидеть привязку моделей в работе, запустите приложение и перейдите на /Home/Index/1. Результат показан на рисунке ниже:

Указанный URL содержит значение свойства UserId объекта User, который необходимо отобразить, например:

/Home/Index/1

Инфраструктура ASP.NET MVC Framework транслирует эту часть URL и применяет ее в качестве аргумента при вызове метода Index() класса контроллера Home с целью обслуживания запроса:

public ActionResult Index(int id)

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

Процесс, приводящий к привязке моделей, начинается сразу после получения запроса и его обработки механизмом маршрутизации. В этом примере приложения конфигурация маршрутизации не изменялась, поэтому для обработки запроса использовался стандартный маршрут, который среда Visual Studio добавляет в файл /App_Start/RouteConfig.cs. В качестве напоминания, этот стандартный маршрут приведен ниже:

Вопросы определения и работы маршрутов подробно рассматривались ранее, поэтому здесь они повторяться не будут

Для процесса привязки моделей важной частью является необязательная переменная сегмента id. При переходе на URL вида /Home/Index/1 последний сегмент, который указывает интересующий объект User, присваивается переменной маршрутизации id

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

Стандартный активатор действий, ControllerActionInvoker, полагается на связыватели моделей при генерации объектов данных, которые требуются для вызова метода. Связыватели моделей определяются с помощью интерфейса IModelBinder, который показан в примере ниже. Мы еще вернемся к этому интерфейсу позже, когда будет рассматриваться создание специального связывателя модели.

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

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

Связыватель модели отвечает за предоставление значения int, которое может использоваться для вызова метода Index(). Это обычно означает трансформацию некоторого элемента данных запроса (такого как значения формы или строки запроса), но инфраструктура ASP.NET MVC Framework никак не ограничивает способ получения данных.

Позже будут предоставлены примеры специальных связывателей. Кроме того, будут продемонстрированы определенные возможности класса ModelBindingContext, экземпляр которого передается методу IModelBinder.BindModel().

RV¶

См.также

• Pyramid wikipedia

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

Паттерн RV (Resources-View)

Веб ограничен URL, который и представляет из себя дерево ресурсов или
структуру сайта.

Также протокол HTTP не позволяет хранить состояние и
отправлять/принимать оповещения клиенту от сервера, что ограничивает
возможность отслеживания действий клиента для последующего уведомления модели
на изменение состояния.

Поэтому данные часто используются на «frontend»-е
(например в связке React/Redux), а на стороне сервера формируются только один
раз во время ответа, либо загружаются отдельным запросом при помощи AJAX, или
даже с помощью других протоколов, например WebSocket.

RV фреймворки:

Каков профит?

Мы рассмотрели подход к проектированию и созданию программных приложений, предусматривающий выделение кода в такие компоненты, как Модель, Представление и Контроллер. Controller в паттерне MVC — это такой компонент, который служит для обработки входящих запросов. Модель извлекает из БД необходимую информацию. Представление определяет визуальный результат.

Основная цель следования таким принципам — разделение реализации бизнес-логики от ее визуализации. Это повышает возможности повторного применения кода, повышает его читаемость, упрощает написание программ, облегчает расширение и техническую поддержку системы в будущем.  

• https://ru.hexlet.io/blog/posts/chto-takoe-mvc-rasskazyvaem-prostymi-slovami;
• https://javarush.ru/groups/posts/2536-chastjh-7-znakomstvo-s-patternom-mvc-model-view-controller;
• https://skillbox.ru/media/code/chto_takoe_mvc_bazovye_kontseptsii_i_primer_prilozheniya/.

Также вам могут быть интересны следующие статьи с примерами реализации MVC на PHP:

Summary

As we have seen, the fundamental idea of MVC is a separation of the domain logic and the GUI objects into the Model and the View. These two are linked indirectly by using the Publish-Subscribe mechanism known as the Observer pattern. Another element of this design is a Controller that implements a particular strategy for the View.

It makes sense to use this pattern when the View is very simple and contains no code, as in the case of web based systems and HTML. This way, the View can build the UI, and the Controller handles the user interactions. Note that Microsoft chose to use this pattern in their ASP.NET MVC framework that targets the web developers.

MVP delegates more work to the View and removes the Controller. It introduces the Presenter class that encapsulates the View’s state and commands. The Presenter can access the View directly. This is perfect for Windows based systems where Views are powerful classes that can encapsulate the events and store items’ state. Note that Microsoft made this a part of the Composite Application Blocks (CAB) framework that targets Windows developers.

The Model – View relationship based on the Observer pattern still exists in MVP; however, the Presenter can access the View directly. Although this is easy to use and implement, developers need to be careful not to break the logic of the system they are trying to model. For instance, the system where the driver accelerates and checks the speed indicator is unlikely to be modeled using MVP. The Driver (Presenter) can update the engine’s state (Model), but now needs to update the speed indicator (View). Surely, more logical is the system where the driver updates the engine’s state (press gas) and the speed indicator will read these changes (the Observer pattern).

The MVVM is a powerful pattern for all WPF developers. It allows to keep the View free from any code and available to XAML designers. The WPF binding serves as a link to the ViewModel that can handle state, implement the commands, and communicate with the domain specific Model.

MVVM resembles Fowler’s PM where the Presentation Model class is called ViewModel.

The Presentation Model is a more general version of MVVM where the developers need to implement the link between the View and the ApplicationModel (ViewModel) themselves. It also allows the View to reference the ApplicationModel, or the ApplicationModel to reference the view. It can be broken down into smaller patterns like Supervising Controller or Passive View where only a specific behaviour is required.

Overall, I hope this paper has achieved its goal to unveil the main GUI patterns and highlight their strengths and weaknesses. It can serve as a good starting point and help you decide what pattern to use when setting out on your next GUI development quest.

История

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

Трюгве Реенскауг представил MVC в Smalltalk -79 во время посещения исследовательского центра Xerox в Пало-Альто (PARC) в 1970-х годах. В 1980-х Джим Альтхофф и другие реализовали версию MVC для библиотеки классов Smalltalk-80. Лишь позже в статье 1988 года в The Journal of Object Technology (JOT) MVC была выражена как общая концепция.

Впоследствии шаблон MVC развился, что привело к появлению таких вариантов, как иерархическая модель – представление – контроллер (HMVC), модель – представление – адаптер (MVA), модель – представление – презентатор (MVP), модель – представление – модель представления (MVVM), и другие, которые адаптировали MVC к разным контекстам.

Использование шаблона MVC в веб — приложениях взрыв популярности после введения NeXT «s WebObjects в 1996 году, который был первоначально написан в Objective-C (что в значительной степени заимствованы из Smalltalk) и помогли обеспечить соблюдение принципов MVC. Позже шаблон MVC стал популярен среди разработчиков Java, когда WebObjects был перенесен на Java . Более поздние фреймворки для Java, такие как Spring (выпущенный в октябре 2002 г.), продолжали прочную связь между Java и MVC. Внедрение фреймворков Django (июль 2005 г. для Python ) и Rails (декабрь 2005 г. для Ruby ), в обеих из которых был сделан сильный акцент на быстром развертывании, повысило популярность MVC за пределами традиционной корпоративной среды, в которой он давно стал популярным.

Заключение

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

Например, упомянутый здесь уже неоднократно Фаулер, выделяет аж три возможных модификации MVP, это Presentation Model, Supervising Controller и Passive View. Все они отличаются исключительно способом взаимодействия Presenter-а и Представления, а точнее способами передачи данных представлению. Если мы себе позволяем передавать в Представление бизнес-объекты, вместо примитивных типов, то это Presentation Model, если же позволили Представлению знать о наличии модели и самому забирать из нее данные, то это Supervising Controller, ну а самый простой случай, когда логика Представления действительно минимальна то с нами Passive View. В каждом конкретном случае выбор между этими тремя модификациями паттерна зависит от того, на сколько умную автоматическую привязку бизнес объектов к интерфейсу Представления вы можете использовать и какая степень покрытия тестами логики Presenter-а вас устроит… Ну и, само собой, от сложности бизнес-объектов и интерфейсов.

Для реальных ситуаций, которые, как правило, несколько сложнее приведенного примера, существуют модификации паттерна позволяющие выстроить определенную иерархию. Выделяют два варианта таких иерархических паттернов – это Hierarchical Model-View-Controller (HMVC) и Presentation-Abstraction-Control (PAC), который пришел из мира Java. Отличие заключается в том, что HMVC позволяет выстраивать независимые иерархии, отдельно для Представлений, отдельно для Контроллера/Presenter-а, ну и само-собой для Модели, с прямыми ссылками между собой, то есть, например, Представление может ссылаться непосредственно на дочернее Представление. В свою очередь PAC, более строгий паттерн, и предписывает иметь связи между собой только Контроллерам, другие сущности доступны извне исключительно через свой Контроллер.

В целом, применение MVP, вместо уже ставшего традиционным Document-View, с одной стороны, несколько увеличивает объем ручного кодирования, однако с другой, позволяет покрыть большую часть логики тестами, уменьшает связность между компонентами и может служить основой для реализации механизма «скинов» (оболочек, шкурок) приложения, вплоть до того, что для одного и того же «движка», можно иметь как Win, так и Web «шкурку».