[MUSIC]
В веб-разработке вы часто слышите, как люди говорят о фреймворке MVC и
фреймворке MVVM и так далее.
Что именно представляют собой эти рамки?
Как они полезны в веб-разработке?
Давайте поговорим об этом вкратце.
В мире разработки программного обеспечения
вы часто слышите, как люди говорят о шаблонах проектирования.
Что именно они означают, чтобы перестать изобретать колесо каждый раз.
Шаблон проектирования является хорошо документированным решением повторяющейся проблемы.
Очень часто вы видите себя неоднократно решая подобные проблемы.
Если у нас есть четко определенная документация о том, как решить эти проблемы,
зачем продолжать изобретать колесо каждый раз?
Таким образом, именно здесь возникает концепция шаблона проектирования программного обеспечения
.
Иногда вы также видите людей, ссылающихся на это как на архитектуру.
Таким образом, шаблоны проектирования программного обеспечения, в частности, являются многоразовым решением
для часто встречающихся проблем, которые решаются в программном обеспечении.
Теперь в этом контексте вы часто слышите, как люди говорят о банде из четверых.
Это была группа из четырех авторов, которые написали эту основополагающую книгу под названием
Design Patterns: Элементы многоразового объектно-ориентированного программного обеспечения.
В этой книге они определили большой набор часто используемых шаблонов дизайна
в программной инженерии.
Это было одним из первых хорошо документированных исследований шаблонов дизайна
и, следовательно, стало золотым стандартом для тех, кто работает в сфере разработки программного обеспечения
, особенно обеспокоенных пакетами проектирования.
Этот шаблон разработки программного обеспечения позволяет изолировать логику домена
от пользовательского интерфейса.
Таким образом, вы в основном отделяете представление пользователя информации
от фактической логики и того, как информация хранится и обрабатывается.
Теперь эта концепция разделения проблем вы собираетесь услышать и
снова в этом контексте.
Разделение проблем - это то, что облегчает независимое развитие
каждой из этих трех частей нашего приложения, а
также позволяет тестировать и поддерживать эти различные части.
Теперь мы можем разделить все наше приложение на три части,
представление, которое в первую очередь связано с представлением информации пользователю,
модель, которая хранит состояние домена и логику домена и
также обеспечивает способ
манипулирования этим состоянием из остальной части приложения и
контроллер, который является посредником между представлением и моделью.
Далее мы поговорим о каждой из этих трех частей чуть более подробно.
В рамках MVC модель управляет поведением и
данных домена приложения.
И модель отвечает на запросы о предоставлении информации о ее текущем состоянии.
Таким образом, как правило, когда представление хочет визуализировать, или представление хочет обновить
само, он может запросить модель, чтобы получить информацию так
, что она может быть отображен соответствующим образом пользователю.
Модель также будет отвечать на запросы об изменении своего состояния.
Это обычно делается через контроль.
В системе, управляемой событиями,
модель также может быть настроена для уведомления наблюдателей.
Таким образом, зрители могут зарегистрироваться в качестве наблюдателей для модели и, следовательно,
при обновлении модели представления будут автоматически запускаться для обновления
на основе изменения этого состояния модели.
Само представление касается представления информации пользователям в элементе интерфейса пользователя
таким образом, что это облегчает как представление информации
пользователю, так и позволяет пользователю взаимодействовать с приложением.
Таким образом, представление может представлять одно представление состояния модели.
Таким образом, из одной модели вы можете легко получить несколько способов
представления этой информации пользователю, в зависимости от примера
, в зависимости от размера окна просмотра.
Таким образом, небольшой размер viewport, как в мобильном приложении,
информация будет представлена по-другому, в отличие от
к более большому порту просмотра, который облегчается на настольном компьютере.
Таким образом, в рамках MVC все отображение информации имеет одно на
одно соответствие с состоянием модели.
Третья часть головоломки в рамках MCV является контроллером.
Заданием контроллера является получение информации из представления.
Таким образом, любое пользовательское взаимодействие, которое выполняется, будет захвачено и
затем передано на контроллер, чтобы действовать на эти взаимодействия с пользователем.
И это задача контроллера тогда инициировать изменение состояния
модели, если это требуется в данной конкретной ситуации.
Таким образом, контроллер соответствующим образом вызовет изменение состояния модели.
Таким образом, чтобы подвести итог, контроллер может принять ввод
от пользователя с точки зрения взаимодействия с пользователем, которые имели место, и
тогда он будет инструктировать модель изменить состояние.
Одновременно контроллер может также
вызвать изменение представления информации в представлении.
Так вот почему на этой картинке у вас есть две стрелки
, идущие от контроллера, одна к модели, а другая к виду.
Иногда вы слышите, как люди говорят о подходе модели представления модели.
Подход модели представления модели является, в некотором смысле,
производной подхода контроллера представления модели.
Иногда вы также слышите, как люди ссылаются на него как на модель
view-binder подхода.
Здесь у вас есть модель, которая представляет бизнес-логику и
данные для вашего приложения.
Из модели выводится модель view-model, которая инкапсулирует ту
часть информации, которая необходима для рендеринга определенного вида.
Таким образом, модель представления представляет собой абстракцию представления, которая предоставляет
общедоступные свойства и различные доступные команды.
Таким образом, это обеспечивает декларативную привязку данных.
В некотором смысле, способ реализации компонента и
шаблонов в угловых, его можно рассматривать как
вариант модели view-model подхода.
С этим быстрым пониманием MVC и MVVM рамки,
давайте теперь перейдем к пониманию больше об угловых службах.
[МУЗЫКА]