Архитектура mvc в java

Начало работы с ASP.NET MVC 4

Последнее обновление: 31.10.2015

После установки всего необходимого инструментария мы можем создать первое приложение. Итак, откроем Microsoft Visual Studio Community 2013 (или
другой имеющийся выпуск Visual Studio 2012 / 2013). В меню File (Файл) выберем пункт New Project… (Создать проект).
Перед нами откроется диалоговое окно создания проекта. Cреди типов проекта выбрем
Web->Visual Studio 2012, а в центральном поле — шаблон ASP.NET MVC 4 Web Application:

После выбора типа проекта перед нами откроется окно выбора шаблона нового приложения:

Выберем шаблон Internet Application. Что представляют все эти шаблоны?

Шаблоны приложения MVC 4

• Internet Application. Данный шаблон представляет некоторую базовую функциональность, например, управление учетными записями,
  которую будет содержать новое приложение.

• Intranet Application. Данный шаблон похож на шаблон Internet Application. Отличие состоит в том, что в Intranet Application для
  управления учетными записями используется аутентификация Windows, а не система ASP.NET Membership.

• Empty. Этот шаблон представляет абсолютно чистое приложение без каких-либо файлов и структуры папок.

• Basic. Этот шаблон также представляет пустой проект. Правда, он содержит базовые каталоги, CSS, инфраструктуру приложения MVC.
  Ранее в MVC 3 этот шаблон назывался Empty.

• Mobile Application. Это новинка MVC 4, предназначенная для создания веб-приложений для мобильных платформ.

• Web API. Предназначен для создания сервисов и для работы с фреймворком Web API.

• Single Page Application. Шаблон, предназначенный для создания сайтов-одностраничников.

• Facebook Application. Предназначен для создания веб-приложений под социальную сеть Facebook.

Кроме того, данное диалоговое окно предлагает нам выбрать движок представления в секции View Engine и задать опции тестирования.

При выборе движка представления нам, как и в MVC 3, доступны две опции — движок Razor и ASPX (традиционный движок Web Forms). В данном случае мы
выберем Razor. Опции тестирования мы пока трогать не будем.

Итак, нажимаем кнопку OK и создаем новый проект. Мы сразу же можем запустить проект на выполнение и нам предстанет чудная картинка в браузере
с нашим приложением:

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

Структура проекта MVC 4

Справа в окне Solution Explorer (Обозреватель решений) мы можем увидеть структуру проекта MVC 4. Тот, кто раньше работал с предыдущими версиями MVC,
заметит некоторые отличия. Итак, пройдемся по папкам и файлам проекта.

App_Data

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

Файл Global.asax и папка App_Start

В mvc 4 была добавлена папка App_Start. Она включает весь функционал конфигурации приложения, который в предыдущих версиях содержался в файле
Global.asax, а теперь перенесен в набор статичных классов, вызываемых в Global.asax. Эти статичные классы содержат некоторую логику инициализации
приложения, выполняющуюся при запуске.

Content

Содержит некоторые вспомогательные файлы, которые не включают код на c# или javascript, и которые развертываются вместе с приложением. В частности,
здесь могут размещаться файлы стилей css. Так, в этой папке вы увидите файл Site.css, который содержит стили приложения, а также папку с темами, включающую
стили css и изображения для определенных тем.

Controllers

Содержит контроллеры — классы, отвечающие за работу приложения. По умолчанию здесь находятся два контроллера — HomeController и AccountController.

Папки Images и Scripts

Папки Images и Scripts содержат соответственно изображения и скрипты на JavaScript, используемые в приложении. По умолчанию эти папки уже содержат
файлы, в частности, в папку Scripts уже помещены файлы библиотеки jQuery.

Models

Содержит модели, используемые приложением. По умолчанию здесь определена одна модель — AccountModel, которая представляет отдельную учетную запись.

Views

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

Итак, мы посмотрели на некоторые базовые части проекта и теперь создадим первое приложение.

НазадВперед

Using the Code

Note: I strongly recommend you download the code to view it, it will be much easier.

Here I will show an example of our good old friend calculator in a MVC architecture. A brief overview; the Form will house the view and events will be passed to the controller who will then call methods on our model such as ADD/Subtract/NumberPress. The model takes care of all the work and it holds the current state of the calculator. The tough thing about MVC is where to slice it apart can be confusing. The end goal is a pluggable UI and perhaps multiple controllers attached to the same model. So one way to test if you did it right is to quickly write another UI and plug it in.

A typical MVC patterns instantiation looks something like the following. A few important things to notice; the controller takes an interface to the view and model. It is important to know that the view will typically interact with the controller if it needs notification of events which are fired via the view (such as a button click). In this case, I have the controllers constructor pass a reference to itself to the view class.

C#
Copy Code

static class Program
{
                
    static void Main()
    {



        Application.EnableVisualStyles();
        Application.SetCompatibleTextRenderingDefault(false);
        frmCalcView view = new frmCalcView();
        CalculatorModel model = new CalculatorModel();
        CalcController controller = new CalcController(model, view);
        Application.Run(view);
    }
}
class CalcController : IController
{
    ICalcModel model;
    ICalcView view;

    public CalcController( ICalcModel model, ICalcView view)
    {
        this.model = model;
        this.view = view;
        this.view.AddListener(this); 
    }

    public void OnClick( int number )
    {
        view.Total = model.SetInput(number).ToString();
    }

    public void OnAdd()
    {
        model.ChangeToAddState(); 
    }
}

Notice that the view does not interact with the model, it simply receives update requests from the controller. The controller will access the view through the Total property. The view also passes click events on to the controller.

This View shouldn’t know about the Controller, except we need to give it notification of some events so we pass in a . We will invoke event handlers on the controller via .

C#
Copy Code

public partial class frmCalcView : Form, ICalcView
{
    IController controller;
    public frmCalcView( )
    {
        InitializeComponent();
    }
                        public void AddListener( IController controller )
    {
        this.controller = controller;
    }
    private void lbl_Click(object sender, EventArgs e)
    {
        
        
        controller.OnClick((Int32.Parse(((Label)sender).Text)));
    }
    private void lblPlus_Click(object sender, EventArgs e)
    {
        controller.OnAdd();
    }

#region ICalcView Members
    public string Total
    {
        get
        {
            return textBox1.Text;
        }
        set
        {
            textBox1.Text = value;
        }
      }
#endregion
}

Now we will take a look at the model. Notice that it should do the «work» of the calculator and it handles the state.

C#
Copy Code

                            class CalculatorModel : ICalcModel
    {
        public enum States { NoOperation, Add, Subtract };
        States state;
        int currentValue;
        public States State
        {
            set { state = value; }
        }
        public int SetInput ( int number )
        {
            if (state == States.NoOperation)
            {
                currentValue = number;
            }
             else if (state == States.Add)
            {
                currentValue = Add(currentValue , number );
            }
            return currentValue;
        }
        public void ChangeToAddState()
        {
            this.state = States.Add;
        }
        public int Add( int value1, int value2 )
        {
            return value1 + value2;
        }
        public int Subtract(int value1, int value2)
        {
            throw new System.ApplicationException(" Not implemented yet");
        }
}

Model-View-ViewModel

Честно говоря, не знаю, используется ли данный паттерн где-то, кроме WPF и Silverlight. Здесь опять присутствуют три компоненты: модель, представление и третий компонент – дополнительная модель под названием ViewModel. Данный паттерн подходит к таким технологиям, где присутствует двухсторонний биндинг (синхронизация) элементов управления на модель, как в WPF. Отличие от MVP паттерна заключается в том, что свойство SelectedRecord, из предыдущего примера, должно находится не в представлении, а в контроллере (ViewModel), и оно должно синхронизироваться с необходимым полем в представлении. Как раз и выходит, что в этом и есть основная идея WPF. ViewModel – это некоторый суперконвертор, который преобразует данные модели в представление, в нем описываются основные свойства представления, а также логика взаимодействия с моделью. Рекомендую ознакомиться со статьей .

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

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

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

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

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

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

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

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

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

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

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

The Controller (C)

The controller layer is the least reusable part of your app as it often involves your domain-specific rules. It should be no surprise that what makes sense in your app won’t always make sense in someone else’s. The controller will then use all the elements in your model layer to define the flow of information in your app.

Usually, you’ll see classes from this layer deciding things like:

• What should I access first: the persistence or the network?
• How often should I refresh the app?
• What should the next screen be and in which circumstances?
• If the app goes to the background, what should I tidy up?
• The user tapped on a cell; what should I do next?

Think of the controller layer as the brain, or engine, of the app; it decides what happens next.

You likely won’t do much testing in the controller layer as, for the most part, it’s meant to kick things off, trigger data loads, handle UI interactions, mediate between UI and model, etc.

What is MVC

With the project handy, it’s time to start learning about the Model, the View and the Controller. But first, what exactly is MVC?

Note: If you already know the concept of MVC, feel free to skip ahead to the next section, where you’ll start getting into best practices.

MVC is a software development pattern made up of three main objects:

• The Model is where your data resides. Things like persistence, model objects, parsers, managers, and networking code live there.
• The View layer is the face of your app. Its classes are often reusable as they don’t contain any domain-specific logic. For example, a is a view that presents text on the screen, and it’s reusable and extensible.
• The Controller mediates between the view and the model via the delegation pattern. In an ideal scenario, the controller entity won’t know the concrete view it’s dealing with. Instead, it will communicate with an abstraction via a protocol. A classic example is the way a communicates with its data source via the protocol.

When you put everything together, it looks like this:

Each one of these objects is meant to be separate from the other, and each fulfills a specific role. When building an app that uses a specific pattern, in this case MVC, the goal is to adhere to the pattern when building all layers of your app.

Apple’s MVC documentation explains these layers in detail and can give you a good theoretical understanding. From a practical perspective, though, it falls a little short.

In this tutorial, you’ll learn to treat MVC as a pattern and not as a strict rule that you must never break. As is the case with many things in software development, nothing is perfect and neither is MVC. There are gray areas that you’ll run into, but no decision you make is the wrong decision. As long as you don’t have files that are too big, or code that is difficult to expand upon, then you’re likely doing a good job. Use MVC — and other patterns for that matter — as architectural guidelines and foundations for your app.

Having said that, it’s time to look at each layer in more detail.

Проблемы понимания MVC

Model — не схема БД, не сущность и не ORM, а модель предметной области

Очень часто моделью называют классы, отображающиеся на сущности схемы БД. Однако в рамках MVC этот термин имеет другой смысл. Model — это модель предметной области, содержащая всю бизнес-логику приложения. В том числе сущности, различные сервисы, репозитории, фабрики и многое другое. Модель хранит состояние и может его изменять в зависимости от действий над ней.

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

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

View — не анемичный шаблон, а активный инструмент представления

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

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

Но в описании MVC говорится, что представление имеет связь с моделью, и может запрашивать у неё данные, а некоторых случаях даже менять состояние модели! (Но от последнего, по моему мнению, по возможности лучше отказаться.)

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

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

Controller — не место для бизнес-логики и подготовки данных для отображения

Контроллер, а в частности его действие (в веб-разработке) является конечной точкой маршрутизации запроса. Всё, что должно сделать действие, это:

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

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

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

Getting Started

As a new iOS developer, there is a huge amount of information you need to master: a new language, new frameworks and APIs, and Apple’s recommended architectural pattern Model-View-Controller, or MVC for short.

The MVC pattern is commonplace in iOS development. While it’s not a difficult pattern to understand and get familiar with, there are things to consider to avoid common pitfalls.

Getting up to speed with iOS development can be a daunting task and, more often than not, MVC doesn’t get as much attention as the APIs or programming language. This can lead to major architectural problems in your apps down the road.

This tutorial will help you avoid common mistakes that lead to apps that are too difficult to extend. You’ll learn a good approach of what (and what not) to do as you use MVC to build out your app using best practices, learned through the years of iOS development.

In this tutorial you won’t be doing any coding. Instead, you will walk through a project that uses MVC with best practices in mind.

Use the Download Materials button at the top or bottom of this tutorial to download the sample project.

Внедрение зависимостей в ASP.NET MVC

Хорошо. Но для того, чтобы следовать всему этому, нужно внедрить зависимости в контроллеры и представления. Как это сделать в ASP.NET MVC? Широко распространена практика внедрения в контроллер через свойства. Эту возможность предоставляют многие библиотеки вроде Autofac или Ninject, но есть и другие варианты, которые следует знать.

Внедрение зависимостей в контроллер через конструктор

Внедрить зависимость в контроллер через конструктор можно двумя способами:

1. или другой инструмент внедрения зависимостей с поддержкой этой функции.
2. Написав свою собственную фабрику контроллеров, и использовав внутри неё любой инструмент для разрешения зависимостей.

Внедрение зависимостей во View через публичные свойства

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

(новый класс-предок представления, файл можно разместить рядом с шаблоном)

(Razor-шаблон представления)

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

Логику получения и подготовки данных для отображения, если она слишком сложна, можно написать, перегрузив метод предка представления, и сохранив полученные данные в защищённые поля, которые можно использовать в шаблоне:

или прямо в шаблоне в блоке C#-кода (что на мой взгляд даже лучше, если нет необходимости писать дополнительные методы для преобразования данных модели в подходящий формат):

Так же в базовом классе этого представления можно описать несколько защищенных методов для обработки данных, которые можно потом использовать в шаблоне.

Внедрение зависимостей во View в ASP.NET MVC Core

Движок Razor в ASP.NET MVC Core позволяет внедрить зависимость с помощью директивы в начале шаблона. На самом деле происходит всё то же создание свойства, но уже не в предке представления, а в самом его классе, генерируемом движком:

Но для этого необходимо, чтобы этот интерфейс был зарегистрирован в методе класса :

Особенности архитектурного шаблона MVC

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

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

• Представления, применяемые для визуализации некоторой части модели в виде пользовательского интерфейса.

• Контроллеры, которые обрабатывают поступающие запросы, выполняют операции с моделью и выбирают представления для визуализации пользователю.

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

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

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

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

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

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

Модель

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

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

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

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

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

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

Контроллер

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

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

История создания MVC

Термин модель-представление-контроллер (model-view-controller) используется с конца 70-х гг. прошлого столетия. Этот шаблон происходит из проекта Smalltalk, выполнявшегося в Xerox PARC, где он был задуман как способ организации ранних приложений с графическим пользовательским интерфейсом. Некоторые нюансы первоначального шаблона MVC были связаны с концепциями, специфичными для Smalltalk, такими как экраны и инструменты, но более широкие понятия по-прежнему применимы к приложениям — и особенно хорошо они подходят для веб-приложений.

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

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

Появление платформы Ruby on Rails привело к возобновлению всеобщего интереса к MVC, и он остается шаблоном реализации архитектуры MVC. С тех пор появилось много других инфраструктур MVC, и все они демонстрировали преимущества архитектуры MVC — разумеется, это относится и к ASP.NET MVC.

Where to go From Here?

MVC is a pattern, a guideline for you to architect your app; it is not a strict set of rules you must adhere to.

As with anything that’s meant to act as a guide, you may disagree with some of the contents or implementations in this tutorial. You can do things in other ways or tweak it to fit your needs. That’s all fine. There are many ways to work with this dough that we call the model-view-controller pattern.

The TL;DR is: If you’ve found changes or tweaks that work for you, your team, your company or your workflow, go for it. As long as your app remains flexible and capable of growing, then you’re good to go.

No architecture, old or new, is a silver bullet and you should always focus on good engineering principles first.

If you have any comments or questions, please join the forum discussion below! I hope you’ve enjoyed this tutorial and learning a little bit more about the MVC pattern.

raywenderlich.com Weekly

The raywenderlich.com newsletter is the easiest way to stay up-to-date on everything you need to know as a mobile developer.

Заключение и литература по теме

Целью статьи я ставил объяснение необходимости применения MVC и Publish-Subscribe в определенных случаях, поэтому тут не были описаны история развития этих шаблонов, варианты их реализации и родственные паттерны.

1. SOLID принципы. Рефакторинг: https://pro-prof.com/archives/1914
2. Юнит-тестирование. Пример. Boost Unit Test: https://pro-prof.com/archives/1549
3. Шаблон проектирования Mediator: https://pro-prof.com/archives/887
4. Э. Гамма Приемы объектно-ориентированного проектирования. Паттерны проектирования / Э. Гамма, Р. Хелм, Р. Джонсон, Д. Влиссидес. – СПб.: Питер, 2009. – 366 с.
5. Тепляков С. В. Паттерны проектирования на платформе .NET – СПб.: Питер, 2015. – 320 с.