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

Введение в привязку моделей

Данное руководство устарело. Актуальное руководство: Руководство по ASP.NET Core

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

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

Чтобы понять смысл привязки, посмотрим на примере. Допустим, мы отправляем на сервер форму с некоторыми данными для модели Book. И в
некотором методе контроллера мы можем получить переданные данные из формы:

public ActionResult Edit()
{
    Book b = new Book();
    b.Name = Request.Form;
    b.Author = Request.Form;
    // .........
}

Однако свойств модели Book, которые надо получить из запроса, может быть множество. Кроме того, вы можете заметить, что поля для ввода свойств
модели имеют имя (атрибут ), совпадающее с именем свойства модели. Чтобы облегчить процесс получения присланных данных и был создан
механизм привязки. Благодаря чему мы можем просто написать:

public ActionResult Edit(Book b)
{
    //.........
}

При этом привязка модели не ограничена POST-запросами и сложными параметрами типа объекта Book. Привязка может также работать и с более простыми
параметрами, например со следующим действием Edit, обрабатывающим HTTP-запрос GET:

public ActionResult Edit(int id)
{
    // ...
}

Привязчики моделей

После сопоставления запроса с некоторым маршрутом контролллеров вызываются специальные компоненты — активаторы действий (action invoker),
которые вызывают нужное действие контроллера и передают в него значения из контекста запроса.
А чтобы сопоставить полученные значения с конкретными параметрами активаторы действий, в частности, активатор по умолчанию — ,
используют привязчики модели (model binder). Привязчики моделей и осуществляют собственно привязку.

Все привязчики моделей должны реализовать интерфейс IModelBinder:

public interface IModelBinder
{
	object BindModel (ControllerContext controllerContext, 
						ModelBindingContext bindingContext);
}

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

Затем привязчик использует специальные компоненты — поставщики значений (value provider) для поиска значений в различных частях запроса.

НазадВперед

Об авторе и техническом ревьювере

Хотя я до этого не сталкивался с работами Кристофера Питта (Christopher Pitt) в рамках его деятельности для PHP-комьюнити, тем не менее, проведя ресерч, я обнаружил, что он в свое время писал достаточно интересные статьи про PHP, некоторые из которых попадали на Хабр в виде переводов и заслуживали достойного внимания. Будем считать, что парень ровный. 

Куда больше в этой книге меня заинтересовал технический ревьювер — Маттиас Нобак (Matthias Noback) — личность абсолютно легендарная в рамках современного php-комьюнити. Если вы работаете в корпоративном сегменте и пишите сложные системы на PHP, то с большой вероятностью вы делаете это на Symfony, а значит вы точно читали или хотя бы слышали об его книге «Один год с Symfony». А его статьи на его персональном сайте хоть и говорят об идеальном мире с идеальным PHP, который никогда не настанет, но все равно весьма поучительны.

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");
        }
}

MVC¶

См.также

• Статья о фреймворке Ruby on Rails
• Концепция MVC для чайников

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

Бешеная популярность данной структуры в Веб-приложениях сложилась благодаря её
включению в две среды разработки, которые стали очень востребованными: Struts и Ruby on Rails. Эти среды разработки наметили пути
развития для сотен рабочих сред, созданных позже.

Паттерн MVC (Model-View-Controller)

• Model — модель, предоставляющая доступ к данным. Позволяет извлекать данные и менять их
  состояние;
• View — представление, отображающее данные клиенту. В веб-программировании
  существует в виде конечных данных (HTML, JSON, …), которые получает
  клиент. Может формироваться при помощи генераторов по заданному шаблону,
  например Jinja2, Mako; или систем для построения интерфейсов по разметке,
  таких, как Windows Presentation Foundation (WPF), либо Qt Widgets; или
  описываться декларативно, как это делается в QML и ReactJs.
• Controller — контроллер, отслеживающий различные события (действия пользователя) и по
  заданной логике оповещающий модель о необходимости изменить состояние системы.

Классические MVC фреймворки:

Паттерн Publish-Subscribe (Издатель-Подписчик)

Если один или несколько объектов в Вашем проекте должны отслеживать изменения другого объекта — гибким решением будет применение шаблона проектирования Publish-Subscribe.

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

В качестве примера, рассмотрим табличные процессоры (MS Excel и аналоги), позволяющие строить разные виды графиков и диаграмм по данным таблицы. При изменении данных в таблице, графики в таких системах могут автоматически перестраиваться. Для этого таблица рассылает уведомление об изменении данных всем, кто на нее подпишется.

Шаблон Publish-Subscribe. Пример использования

На диаграмме показаны основные элементы шаблона:

• AbstractSubscriber, задает интерфейс подписчиков;
• EyeChart, один из реальных подписчиков (легко могут быть добавлены другие виды диаграмм). Хранит ссылку на издателя, при помощи которой получает его обновленное состояние после получения сигнала об обновлении данных;
• AbstractPublisher, задает интерфейс издателей. Может реализовывать этот интерфейс (не являться абстрактным), т.к. все издатели должны одинаково добавлять/удалять подписчика и уведомлять их об обновлении;
• SpreadSheet, таблица с данными, уведомляющая подписчиков об изменении своих данных.

В результате применения шаблона:

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

Wrapping up

MVC is a framework for thinking about programming, and for organizing your program’s files. To signify the idea that your code should be organized by its function, developers will create folders for each part of MVC. (The idea that apps should be divided based on the function of each part of the code is sometimes referred to as separation of concerns.) If you’ve looked at Codecademy’s Ruby on Rails course, you might have noticed that there is a folder for each part of MVC within every Rails app it introduces.

MVC gives you a starting place to translate your ideas into code, and it also makes coming back to your code easier, since you will be able to identify which code does what. In addition, the organizational standard MVC promotes makes it easy for other developers to understand your code.

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

Привязка моделей представляет собой элегантный мост между 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().

Модель-представление (model-view)

Шаблон MVC направлен на отделение данных и логики (модели) от интерфейса (представления) программы. Так, например, при разработке игры «Тетрис» к модели могут относится массив с фигурами и логика игры, а представление отвечает за отображение этого массива на экране.Такое разделение соответствует принципу единой обязанности (SRP) , соблюдение которого обеспечивает:

• лучшую тестируемость кода, т.к. вы можете писать unit-тесты к модели и виду независимо друг от друга, что позволит более точно выявлять место с ошибкой при провале какого-либо из тестов ;
• ослабление зависимостей между видом и представлением, а значит более высокую гибкость. В любой момент заменить одно представление на другое, т.к. теперь модель не зависит от представления. В частности замена представления может быть необходима при переносе программы на мобильную платформу с другим пользовательским интерфейсом;
• снижение сложности проекта также является следствием ослабления зависимостей. Разрабатывать отдельные части можно дать программистам с более низкой квалификацией.

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

Модель и представление игры Тетрис

Это здорово, но откуда представление узнает, что в модели какие-либо данные изменились? — при использовании MVC для этого используется шаблон проектирования publish-subscribe.

MTV¶

Фреймворк Django ввел новую терминологию MTV.

Примечание

В Django функции, отвечающие за обработку логики, соответствуют части
Controller из MVC, но называются View, а отображение соответствует части
View из MVC, но называется Template. Получилось, что:

• M -> M Модели остались неизменными
• V -> T Представление назвали Templates
• C -> V Контроллеры назвали Views

Так появилась аббревиатура MTV.

TADA!! Django invented MTV

Вся логика при таком подходе вынесена во View, а то, как будут отображаться
данные в Template. Из-за ограничений HTTP протокола, View в Django
описывает, какие данные будут представленны по запросу на определенный URL.
View, как и протокол HTTP, не хранит состояний и по факту является обычной
функцией обратного вызова, которая запускается вновь при каждом запросе
по URL. Шаблоны (Templates), в свою очередь, описывают, как данные
представить пользователю.

Паттерн MTV (Model-Template-View)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

RV¶

См.также

• Pyramid wikipedia

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

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

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

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

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

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

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.

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.

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

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) и дальше идет пошаговая реализаций этой концепции. В частности я читал подобные книги про MVC на примере Python и Java. И по моему мнению, данная книга является не самым лучшим представителем этого формата.  

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

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

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

Плюсы в этой книге есть без всякого сомнения, но стоят ли они своих денег — это вопрос.