MVC
ModelViewController (MVC) - это модель разработки пользовательского интерфейса компьютера, которая разделяет логику представления информации и взаимодействие с пользователем; Модель содержит данные приложения и бизнес -логику; Контроллер отвечает за преобразование пользовательского ввода в команды и передачу его в модель и просмотр; Это объяснение Википедии;
Эта модель была первоначально разработана Trygve Reenskaug при работе с Smalltalk-80 (1979), и впервые была названа модельной контролера-управляющим; Позже, благодаря глубокому внедрению книги «Паттерны дизайна: элементы многоразового объектно-ориентированного программного обеспечения», MVC стал совершенно популярным;
Поймите обязанности составления трех частей MVC и того, что предоставляют нам существующие фреймворки JavaScript, чтобы мы могли лучше использовать эти рамки. Далее мы сначала передадим три части, которые составляют MVC, чтобы узнать, каковы обязанности каждой части [в качестве примера] Демонстрационный код с основой].
Модель
Модель управляет данными приложений. При изменении данных модели его слушатель будет уведомлен [вероятно, представление]. После получения уведомления слушатель внесет соответствующие изменения.
Вид
Просмотр является визуальным представлением текущей модели состояния. Представление будет наблюдать за изменениями модели и будет уведомлен при изменении модели, и позволяет представлению обновляться. Как правило, мы будем использовать шаблонный двигатель, чтобы отобразить модель в представлении;
Контроллеры
Контроллеры - это посредник между моделями и представлениями. Его задание состоит в том, чтобы обновить представление при изменении модели, и обновить модель, когда пользователь управляет представлением.
Javascipt MVC Сравнение структуры
У разных людей разные методы сравнения, ключ зависит от того, на что вы обращаете внимание:
1. Если вы уделяете больше внимания деталям маршрутизации URL -адреса, хранения данных, просмотра реализации и т. Д., Вы можете сосредоточиться на этом, Throne JavaScript: Framework Sword;
2. Если вы уделяете больше внимания конкретным примерам структуры, здесь существует проект с открытым исходным кодом, который использует различные фреймворки MVC JavaScript для той же демонстрации. Вы можете четко увидеть различия в конкретных приложениях каждой структуры. Вот официальный сайт ToDomvc
Преимущества MVC приносят нам:
1. Легко поддерживать
2. Размещение представления модели означает, что бизнес -логика может быть лучше проверена.
3. Код можно лучше использовать повторно
4. Модульная разработка может сделать разделение труда более яснее, некоторые люди сосредоточены на бизнес -логике, а некоторые люди сосредоточены на пользовательском интерфейсе.
5. После просмотра классической модели MVC мы понимаем концепцию наслоения в приложении и обязанности каждого уровня. В то же время мы должны быть в состоянии идентифицировать различия между всеми фреймворками MVC JavaScript и классической моделью MVC, которую мы объясняем. Таким образом, при выборе структуры MVC мы должны сосредоточиться на том, как реализуются модели, представления, контроллеры, и даже как реализовать определенные коды, чтобы помочь нам лучше выбрать наиболее подходящую структуру JavaScript MVC.
MVVM
Полное имя MVVM - модель ViewModel. Эта архитектурная модель была первоначально предложена Microsoft Martinfowler в качестве спецификации модели проектирования презентационного уровня Microsoft. Это производная модели MVC. В центре внимания модели MVVM уделяются платформы разработки пользовательского интерфейса, которые могут поддерживать управляемые событиями, такие как HTML5, [2] [3] Фонд Presentation Windows Presentation (WPF), Silverlight и T ZK Framework, Adobe Flex.
Большая часть реализации этой модели отделяется от других слоев путем объявления связывания данных на уровне представления, что облегчает разделение труда между разработчиками фронт-энда и застройщиками. Разработчики фронт-эндов записывают связанные данные в ViewModel в теге HTML. Model и ViewModel-это первые разработчики, которые поддерживают эти два уровня через логику разработки приложений.
В последние годы модель MVVM начала реализована в JavaScript. В настоящее время относительно зрелые рамки включают нокаутирование, Kendo MVVM и Nockback.js. Давайте возьмем nockoutjs в качестве примера, чтобы увидеть конкретные обязанности и примеры кодов каждой части модели MVVM, и в то же время понять преимущества и недостатки использования этой модели для разработки.
Модель
Как и другие члены семейства MV*, модель представляет данные в конкретном поле или данных, необходимых для приложения, типичные данные, конкретные, такие как информация пользователя [имя пользователя, аватар, электронная почта, номер телефона] или музыкальная информация [имя песни, год выпуска, альбом];
Модель фокусируется только на информации данных и не заботится о каком -либо поведении; Он не форматирует данные и не влияет на отображение данных в браузере, что не является его ответственностью; Форматирование данных является задачей слоя представления, а слой бизнес -логики инкапсулируется в модели представления для взаимодействия с моделью.
Более неожиданное поведение, сделанное в модельном уровне, - это проверить данные. Например, когда пользователь входит в электронную почту, определите, является ли формат электронной почты правильным.
В NockoutJS модель в основном реализована в соответствии с вышеуказанным определением, но будет служба сервера вызова AJAX для чтения и записи данных модели.
Вид
Просмотр относится к части приложения, которая напрямую взаимодействует с пользователем. Это интерактивный пользовательский интерфейс для представления состояния ViewModel. Представление считается активным, а не пассивным? Это предложение означает, что пассивное представление не заботится о домене модели в приложении, а область модели поддерживается в контроллере; Активное представление MVVM включает в себя привязку к данным, события и поведение модели и ViewModel необходимо понять. Хотя это поведение может соответствовать атрибутам, представление по -прежнему необходимо реагировать на событие ViewModel, и представление не несет ответственности за контроль состояния.
Просмотр слоя nockoutjs - это простой HTML -документ, который будет связан с объявлением данных ViewModel. В то же время, слой представления nockoutjs отображает данные, полученные из ViewModel, передает команды в ViewModel и обновляет измененное состояние ViewModel.
ViewModel
Можно считать, что ViewModel - это контроллер, специально используемый для преобразования данных. Он может преобразовать информацию в модели в информацию в представлении и в то же время передавать команды из представления в модель;
В этом смысле ViewModel больше похожа на модель, но она управляет большим количеством логики отображения представления. В то же время ViewModel также выявляет некоторые методы для поддержания состояния представления и обновления модели в соответствии с поведением и событиями представления;
Таким образом, ViewModel расположена за уровнем пользовательского интерфейса, и обнаружение данных для представления может рассматриваться как источник данных и поведения слоя представления;
Nockoutjs интерпретирует ViewModels как отображение данных и поведения, выраженных в пользовательском интерфейсе. Это не модель данных, которую необходимо сохранить, но она может держать данные, хранящиеся пользователем. ViewModels Knockout реализуется с использованием объектов JavaScript, и нет необходимости заботиться о тегах HTML. Этот абстрактный метод может сделать их реализацию простой.
преимущество:
1.MVVM облегчает параллельное развитие, так что разработчики фронта и затраты на среднее значение не влияют друг на друга.
2. Аннотация слой представления, сокращение бизнес -логики в коде
3.ViewModel легче тестировать, чем управляемое событиями
4. Проверка ViewModel не нужно заботиться об автоматизации и взаимодействии пользовательского интерфейса
недостаток:
1. Для простого пользовательского интерфейса с использованием MVVM слишком тяжелый
2. Декларативное привязка данных не способствует отладке, поскольку императивный код может легко устанавливать точки останова, и этот режим не способствует установке таких точек останова.
3. Переплет данных может создать много книжного хранения в нетривиальных приложениях. Вы также не хотите получить более сложную ситуацию, в которой связывание сложнее, чем связанный объект.
4. В больших приложениях трудно спроектировать слой модели представлений перед получением большого количества обобщений.