В течение этого периода времени, в связи с потребностями моей работы, я провел глубокое исследование фреймворка Nuxt.js и кое-что узнал из него, поэтому я записал его и поделился им. Я лично высоко ценю Nuxt.js, и я даже думаю, что архитектурный шаблон этого фронтенд-инженерного решения — очень хорошая практика, на которой нам нужно учиться и учиться. Цель написания этой статьи не в том, чтобы научить пользоваться Nuxt.js или узнать что-то о нем. Просто поделился некоторыми идеями по архитектуре внешнего интерфейса из того, как Nuxt.js решает различные проблемы разработки. Конечно, если вы лучше понимаете следующие пункты знаний, вы можете углубить свое понимание этой статьи.
Решения и платформы
Совокупность методов решения общей задачи определенного типа, которую можно назвать解决方案, который многие также назвали бы框架. Способ решения проблемы и окончательный ожидаемый результат будут определять окончательную форму решения, вводя официальное определение Nuxt.js:
Nuxt.js — это универсальная платформа приложений, основанная на Vue.js.
Nuxt.js в первую очередь фокусируется на рендеринге пользовательского интерфейса приложений, абстрагируя инфраструктуру клиент/сервер.
Наша цель — создать гибкую структуру приложений, на основе которой вы сможете инициализировать код инфраструктуры для новых проектов или использовать Nuxt.js в существующих проектах Node.js.
Мы можем понять, nuxt.js в основном для разрешения рендеринга интерфейса для веб-приложений解决方案.
Значение существования решения состоит в том, чтобы помочь разработчикам, использующим решение, избежать сложной и повторяющейся работы.В большинстве случаев это помогало разработчикам выполнять большой объем работы, не связанной с бизнесом или избегать интеграции решений, которые подвержены ошибкам. Для разработчиков, которые используют решение, решение обычно состоит из следующих элементов:
- Прозрачен для разработчика, который его использует (можно использовать, не зная конкретных практик внутри фреймворка).
- Абстрактная инкапсуляция верхнего уровня, основанная на выборе одной или нескольких базовых технологий.
- Предоставьте конфигурацию, механизм подключаемых модулей или API для разделения и разделения структуры и конкретной бизнес-реализации.
- Есть определенная стоимость обучения (вторичное развитие конкретного бизнеса на базе фреймворка)
Nuxt.js превосходен в этих трех аспектах, и пользователи, которые не понимают внутренний исходный код Nuxt.js, также могут его использовать. Nuxt.js внутренне использует Vue, Babel, Webpack и т. д. в качестве выбора базовой технологии для поддержки структуры верхнего уровня и реализует разделение конкретных предприятий.Использование Nuxt.js может независимо развивать бизнес, нужно только изменить конфигурацию и используйте Nuxt.js Предоставленные пользовательские компоненты или API-интерфейсы могут завершить разработку определенных услуг.
Все универсальные решения или фреймворки имеют общую цель:Повышение производительности разработчиков.
Тип решения
Как решение проблемы инженерное решение представляет собой абстрактное понятие, которое можно условно разделить на следующие два типа из сценария решения проблемы:
- Проблемы со средой выполнения
- Проблемы во время инженерной разработки, сборки и отладки
Иногда полное решение может учитывать несколько сценариев или может быть сосредоточено на решении одного сценария проблемы.Например, jQuery фокусируется на решении проблем во время выполнения. Vue, на который опирается Nuxt.js, решает несколько проблемных сценариев.Основой Vue является решение проблемы рендеринга пользовательского интерфейса в среде выполнения, и решение получено из инженерных каркасов, разработки, отладки сборки и т. д. и даже браузера Chrome DevTool. план отладки и т. д.
Однако, если тип разделен с точки зрения конкретной проблемы, решаемой решением, типы становятся намного сложнее.Все пакеты, опубликованные на NPM, представляют собой небольшие решения для решения определенного типа проблемы. Хотя существует множество решений, отличное решение должно включать в себя несколько отличных дизайнерских идей.Аспекты дизайна мы подробно обсудим позже.
Архитектурный дизайн
Что нужно сделать, чтобы разработать хорошее решение? Что нужно спроектировать, чтобы разработчики, использующие решение, могли лучше решать проблемы, возникающие при разработке?
Многие новички в области интерфейса или других областях очень увлечены и готовы находить проблемы и обобщать проблемы, а затем писать небольшие решения, такие как библиотеки и инструменты. Это, безусловно, хорошо, но то, что часто пишут, трудно широко использовать или даже нельзя использовать, и почему такое решение, как Nuxt.js, так легко принять и использовать всеми? Это не означает, что новички не нашли или не решили проблемы, но они плохо спроектировали эти решения, что мешает другим разработчикам удобно решать задачи, поэтому необходимо говорить о проектировании архитектуры.
модульный
Будь то архитектура кода или дизайн продукта, самым основным принципом является модульность дизайна.Ранний код js напрямую складывается в определенный файл, и невозможно говорить о каком-либо архитектурном проекте с кодом, полным глобальных переменных. Общая степень детализации модуляризацииПредназначен для определенной функции, модуль может иметь свой собственный вход или выход, но внутри модуля должна выполняться определенная функция. Модуль в объектно-ориентированной разработке программного обеспечения обычно представляет собой объект или класс. Примерно можно понять, что модуль показан на следующем рисунке:
Модульность веб-интерфейса JS не является исключением.С учетом популярности ES6 JS является почти полностью объектно-ориентированным языком. Таким образом, с точки зрения архитектуры внешнего интерфейса, модульность — это самый базовый проект, который мы должны сделать. Что касается модульных концепций AMD, CMD и UMD, я не буду здесь вдаваться в подробности, вы сами в них разберетесь.
Преимущество модульности заключается в том, что сложные системы можно непрерывно декомпозировать.Конечным результатом является то, что сложная система состоит из нескольких модулей, а модули связаны и взаимодействуют посредством ввода и вывода и API. Модульная конструкция также соответствует законам природы, так же как человеческое тело состоит из нескольких системных модулей, и каждый системный модуль состоит из соответствующих тканевых модулей, а тканевые модули состоят из клеточных модулей, которые не зависят друг от друга. друг друга., и сотрудничать, и, наконец, может поддерживать нормальную физиологическую функцию человеческого тела. То же самое касается архитектурного дизайна.
высокая сплоченность
Сплоченность — это мера степени корреляции между компонентами внутри модуля. Сплоченность относится к одному модулю. В архитектурном проектировании мы ожидаем, что полная функция представлена в виде полного модуля, и мы не хотим, чтобы функция требовала, чтобы несколько модулей функционировали в пакетном режиме. Например, с точки зрения структуры человеческого тела, если ваша телесная функция все еще нуждается в поддержке третьей стороны, это будет проблемой. Мы ожидаем, что человеческое тело может независимо завершить свой собственный процесс жизнеобеспечения как целостная личность. Таким образом, структура человеческого тела представляет собой высокосплоченную модель дизайна.
Как показано ниже, интерьеры трех больших модулей очень сплочены:
В архитектурном проектировании лучшим решением проблемы является предоставление только одного модуля, который может быть совместно связан для решения этой проблемы внутри, но внешне только два или более модуля могут решить проблему. Например, в интерфейсном инженерном решении Nuxt.js Babel фокусируется только на решении проблем компиляции ES6, Webpack фокусируется на решении проблем построения, а vue фокусируется на решении проблем рендеринга пользовательского интерфейса. И Nuxt.js как сам модуль тоже ориентирован на решение проблемы рендеринга пользовательского интерфейса.
низкое сцепление
Сцепление — это мера степени зависимости между модулями. Связывание касается модулей и зависимостей между модулями. Поскольку все модули имеют затраты на обслуживание, когда модуль A зависит от модуля B, модификация модуля B неизбежно повлияет на модуль A. Если зависимости между модулями сложны, стоимость последующего обслуживания продукта невообразима, как показано на рисунке. показан следующий рисунок:
В показанной выше архитектуре, если какой-либо модуль нужно модифицировать и обновить по желанию, это будет иметь катастрофические последствия для всей системы. Конечно, в обычной архитектуре такого плохого дизайна не будет.Обычно некоторые разработчики решений могут рассмотреть проблему уменьшения связанности, поэтому они будут выполнять некоторый многоуровневый дизайн, комбинируя бизнес-модули и базовые модули, не относящиеся к бизнесу. теперь многие отличные сторонние библиотеки или фреймворки также предлагают нам выполнять расслоение архитектуры. Но даже так, есть еще некоторые проблемы.
На следующем рисунке показана очень плохая иерархическая схема: бизнес-модуль справа в значительной степени зависит от базового модуля слева, и изменения в бизнес-модуле, вероятно, повлекут за собой изменения всего базового модуля.
Разработчикам необходимо одновременно поддерживать бизнес-модули, а иногда поддерживать кучу «базовых модулей» или «вторичную разработку базовых модулей», хотя эта архитектура не повлияет на все тело, по крайней мере, базовые модули не зависят от бизнеса. модулей, но просто представьте себе такой сценарий:
Когда вы используете Vue-router, вам нужно добавить правило маршрутизации, мы все знаем, что вам нужно поддерживатьrouter.jsфайла, а затем соответствуют пути и бизнес-компонентам маршрута соответственно. Если вы хотите изменить параметры маршрутизации позже, вам необходимо изменить их одновременно сrouter.jsА комплектующие или все-таки совсем напрягает? Даже если вы используете механизм загрузчика Webpack для проксирования некоторых маршрутов, он еще более беспомощен.
Nuxt.js использует собственный внутренний механизм инкапсуляции для сопоставления компонентов в папке страницы с файлом маршрутизации и автоматической настройки файла маршрутизации, что эквивалентно полной развязке схемы маршрутизации, и разработчикам больше не нужно об этом беспокоиться.router.jsфайл, просто сосредоточьтесь на своей собственной папке страницы и файлах компонентов в ней Это типичный пример уменьшения связанности.
разъединение
Развязка — интересная тема.Преимущество развязки в том, что она позволяет разработчикамНе только пользуйтесь удобством решения, но и освобождайте бизнес-логику от ограничений самого решения.. Конечно, полная развязка невозможна. Поскольку бизнес-модули должны использовать базовые модули, предоставляемые решением, неизбежно возникнет связанность. Здесь мы только объясним, как минимизировать связь.
Разделение может в основном следовать трем принципам:
- многослойный дизайн
- односторонняя зависимость
- абстракция службы
Многоуровневый дизайн легче понять, то есть разделить разные модули на определенные уровни, все модули на каждом уровне похожи и сосредоточиться на чем-то одном, например, на архитектуре MVC, которая является очень типичным многоуровневым дизайном. Каждый уровень завершает свой собственный конкретные задачи независимо друг от друга. M фокусируется на данных, V фокусируется на отображении представления, а C фокусируется на бизнес-логике. Каждый уровень связан с фиксированным потоком данных и потоком событий, так что бизнес-логика и базовая архитектура могут быть практически реализованы.
Односторонние зависимости, как следует из названия, предназначены для уменьшения двусторонних зависимостей.Один уровень вызывает API другого уровня или получает события. Преимущество этой схемы заключается в том, что изменения на вызывающем уровне не повлияют на вызываемый уровень, а вероятность того, что вызываемый уровень будет изменен, определенно ниже, чем у вызывающего уровня в проекте, что также очень полезно для разделения всей архитектуры. . Как показано на рисунке ниже, это типичная иерархическая структура и модель односторонней зависимости:
Базовый уровень имеет меньше изменений по сравнению со служебным уровнем, а сервисный уровень имеет меньше изменений по сравнению с бизнес-уровнем.Такая единственная зависимость может уменьшить взаимное влияние между модулями.Обычно, как сторонний базовый модуль, вероятность Изменений API очень мало, но мы Поскольку уровень службы напрямую ориентирован на пользовательский интерфейс или разработчиков, он может время от времени меняться, но мы не ожидаем, что большинство бизнес-модулей необходимо модифицировать без изменения службы.В настоящее время нам необходимо рассмотрим метод абстракции верхнего уровня для разделения.
Абстракция службы в основном фокусируется на уровне службы, который ближе всего к пользователю, но имеет слой, отделенный от бизнес-модуля. Мы надеемся, что изменение модуля службы не повлияет на бизнес-модуль.В настоящее время мы должны дополнительно абстрагировать уровень службы и создать абстрактную службу, соответствующую каждому бизнес-модулю, чтобы изменение бизнес-модуля не повлияло на бизнес-модуль. Сервисный модуль, поскольку существует интерфейсное соединение абстрактной службы, и модификация конкретного модуля службы не повлияет на бизнес-модуль.
На основе приведенного выше обсуждения будет создана модель архитектуры, показанная на следующем рисунке:
Абстрактная служба ссылается на конкретный модуль службы внутри и использует метод конфигурации в качестве связанной записи с бизнес-модулем, так что разработчику нужно обратить внимание только на бизнес-модуль и модуль конфигурации, чтобы конкретная реализация внутри конкретный Framework прозрачен для разработчика. И Nuxt.js использует этот метод, чтобы отделить решения, которые он предоставляет, и разработчикам нужно сосредоточиться только на своем бизнесе иnuxt.config.jsКонфигурация может реализовать полный проект Vue.
Подключаемый дизайн
Для простого в использовании решения чем больше у вас свободы для разработчика на основе решения проблемы, тем лучше, потому что вы не можете попросить разработчика разработать то же самое, например, в Nuxt.js проект, пользователи разработки имеют право использовать свою любимую библиотеку пользовательского интерфейса, право использовать сторонние плагины Webpack, право использовать JSX и так далее. Если этого недостаточно, вы можете посмотреть на компьютер.Интерфейс USB представляет собой съемную конструкцию, к которой можно подключить мышь, клавиатуру, U-диск и т. Д.
Так как же определить подключаемый дизайн?
Используйте его, когда хотите, не используйте, когда не хотите
Преимущество подключаемости заключается в том, что она может улучшить взаимодействие с пользователем.На основе выбора базовой базовой технологии она может предоставить набор подключаемых интерфейсов, чтобы помочь разработчикам добавлять больше пользовательских вещей. Просто следуйте согласованному интерфейсу, чтобы получить доступ к контенту, настроенному третьей стороной. можно вставить в основную раму. Типичные проекты включают механизм подключаемых модулей Webpack, механизм подключаемых модулей Babel и т. д., которые все реализованы на основе ловушек. Следовательно, когда мы проектируем архитектуру, мы можем отсортировать набор конвейерных процессов для наших собственных решений, и мы можем попытаться установить подключаемый подключаемый механизм, основанный на теневом цикле процесса через механизм триггера событий перехватчиков.
драйвер конфигурации
Отличительной особенностью Nuxt.js является то, чтоnuxt.config.jsфайл, этот файл представляет почти все функции, предоставляемые Nuxt.js, то есть знания разработчиков о Nuxt.js могут быть сосредоточены в этом файле, и основная стоимость обучения исходит только от этого файла.
С помощью конфигурации функциональные модули, предоставляемые Nuxt.js, решают проблему бизнес-модулей. В частности, интерфейсные инженерные решения особенно подходят для реализации на основе конфигурации.
На самом деле существует множество практик, основанных на конфигурации, и все без исключения эти основанные на конфигурации практики чрезвычайно удобны для разработчиков. Например, конфигурация Webpack, конфигурация может решить все проблемы, какая разница, какие функциональные модули предусмотрены внутри Webpack? Кого волнует, изменились ли внутренние функциональные модули после обновления Webpack? Может быть, всех больше волнует, была ли изменена эта конфигурация. Есть также отличные проекты, такие как экспресс и коа, Кого волнует, как их внутренности заставляют сервер работать? Что всех больше беспокоит, так это то, может ли интерфейс, настроенный в соответствии с вашим руководством, работать нормально.
Таким образом, подключаемые модули, промежуточное ПО и конфигурация должны быть ключевым аспектом проектирования архитектуры интерфейсных инженерных решений.
Затраты на обучение и ограничения
Ничего нельзя сделать напрямую, архитектура Nuxt.js достаточно проста и понятна, даже если внутренний выбор технологий вам знаком, вы не можете просто использовать Nuxt.js для сборки проекта. Любое решение требует затрат на обучение, но стоимость обучения у разных решений определенно разная. Мы говорим, что стоимость обучения jQuery связана с его API, стоимость обучения Vue и React — его концепцией дизайна и API, а стоимость обучения Webpack — его загрузчиком и плагином и так далее.
DSL
DSL (Domain Specific Language) — доменно-ориентированный язык Звучит круто, но это слово используется во многих решениях Что такое DSL?
WikipediaОпределение DSL относительно простое:
A specialized computer language designed for a specific task.
Компьютерный язык, специально разработанный для решения определенного класса задач.
Противоположностью DSL является GPL (язык общего назначения), то есть языки Objective-C, Java, Python и C, с которыми мы хорошо знакомы. В отличие от GPL, DSL полностью отличается от традиционных языков программирования общего назначения C, Python и Haskell. Язык компьютерного программирования общего назначения может использоваться для написания любой компьютерной программы и может выражать любую логику, которую можно вычислить.Полнота по Тьюрингуиз.
Но DSL, о которых мы говорим сегодня, не являются полными по Тьюрингу, они имеют ограниченную выразительную силу и решают только определенные задачи в определенных областях.
A computer programming language of limited expressiveness focused on a particular domain.
DSL торгует эффективностью в определенной области, жертвуя выразительностью, и ограниченная выразительность становится границей между GPL и DSL.
Было представлено так много DSL, так как же это связано с сегодняшней темой решений и затрат на обучение? Обычно при предоставлении решения для более четкого выражения предоставляемых решением возможностей обычно используется метод описания DSL для предоставления его пользователям, или он недостаточно популярен? Короче говоря, разработчик общего решения разрабатывает набор синтаксического сахара для использования пользователями.Синтаксический сахар можно понимать как набор небольших DSL. Например, настройка Nuxt.js<nuxt>Метки можно понимать как небольшой DSL. По большому счету, набор решений может быть совершенно новым языком. Как пользователь, вы должны выучить этот язык. Этот язык также можно рассматривать как
DSL. Например: однофайловая инженерная разработка, предложенная Vue,.vueФайл, хотя и прост для понимания, уже имеет характеристики DSL.
Одной из характеристик DSL является то, что решение или сам фреймворк должен предоставлять компилятор для внутренней компиляции, в противном случае нормальный контекст выполнения проекта не может быть подключен, и конечный продукт все равно должен вернуться на GPL. Однако процесс компиляции, конечно, также зависит от сложности DSL.
Для архитекторов решений также важна разработка элегантного DSL. Хотя решения или фреймворки требуют затрат на обучение, отличный дизайн DSL может значительно снизить затраты на обучение пользователей.Причина, по которой Vue стал популярным, заключается в том, что грамматические особенности объявлений меток, которые сочетают синтаксис html и js, сокращают обучение.Чен Бен также имеет значительные отношения.
Нет правил нет стандартов
Я узнал от Nuxt.js, что разработка должна быть разделена в соответствии со структурой каталогов и модулями кода, заданными Nuxt.js. Некоторые папки также четко сообщают, что модификация не разрешена. На первый взгляд, это очень несовместимо с вышеупомянутым «освобождением». Манифест ".Разработчики, дайте разработчикам свободу" мне непонятен
Однако в качестве решения, особенно решения, которое контролирует весь процесс внешнего интерфейса от инициализации до развертывания, его следует ограничить, когда конфигурация не может покрыть развязку, что можно рассматривать как передовую практику. Как говорится в старой поговорке "Нет правил, нет круга", чрезмерная свобода - это преступление :)
В архитектурном дизайне решения могут быть раскрыты некоторые ограничения типов передовой практики, чтобы пользователи могли ограничивать себя, а не ограничивать в архитектуре самого решения.Настраиваемый дизайн имеет влияние. Конечно, пока есть ограничения, стоимость обучения будет увеличиваться, а пользователям необходимо самим понимать смысл этих лучших практик, поэтому при проектировании архитектуры решения необходимоТщательно разработайте правила, установленные лучшими практиками.
напиши в конце
Вышеизложенное является некоторыми личными мыслями, основанными на Nuxt.js, и может не иметь полного понимания Nuxt.js или некоторых проблем. Комментарии и исправления приветствуются.
Эта статья является оригинальной статьей, и точки знаний будут часто обновляться, а некоторые ошибки будут исправлены.Поэтому, пожалуйста, сохраняйте первоисточник для перепечатки, что удобно для отслеживания источника, избежания введения в заблуждение устаревшими неправильными знаниями и наличия лучший опыт чтения.
При воспроизведении указать источник:Перейдите на Miaojiang.com/article/…