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

Архитектура внешний интерфейс
Видеть суть через явление: распространенные стили и кейсы архитектуры фронтенда

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

Приведенное выше определение помнят немногие.Следует отметить, что данная статья не является профессиональной статьей по системной архитектуре, и автор не достиг этого уровня, поэтому не стоит беспокоиться о том, что такое архитектурный паттерн, а что такое архитектурный стиль. это здесьДавайте возьмем их все как рутину системной архитектуры.Так называемая рутина - это некоторые общие и многократно используемые методы для решения определенных типов проблем.Его можно понимать как что-то похожее на «шаблон проектирования», который является только решением проблемы метод разные уровни.

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

Схема статьи


многослойный стиль

Нет проблемы, которую нельзя было бы решить с помощью слоев, если ее нельзя решить, добавьте еще один слой, — Лу Синь.

Нет-нет, исходное предложение:Any problem in computer science can be solved by anther layer of indirection.

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

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

  • Это мощный инструмент для разделения сложности бизнеса и технической сложности.Типичным примером является сетевой протокол.Верхние уровни больше ориентированы на человека, а нижние уровни больше ориентированы на машины. Слой за слоем скрываются многие технические детали, такие как мы используемHTTP, не надо рассматриватьTCPДетали рукопожатия уровня и передачи пакетов,TCPСлоям не нужно заботитьсяIPУровневая адресация и маршрутизация.


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


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

В области программного обеспечения слишком много случаев многоуровневой архитектуры, давайте поговорим о некоторых «многоуровневых» случаях во внешнем интерфейсе:


Virtual DOM

В каменном веке взаимодействие со страницей и ее рендеринг осуществлялись посредством рендеринга на стороне сервера или прямого манипулирования DOM, что было немного похоже на ручное манипулирование памятью с помощью языков системного программирования, таких как C/C++.JQueryочень жарко:

Позже, когда производительность программного и аппаратного обеспечения становилась все лучше и лучше, а веб-приложения становились все более и более сложными, производительность разработчиков интерфейсов должна была поддерживаться. Императивные методы программирования, такие как JQuery, несомненно, были неэффективными. Хотя ручное манипулирование DOM Может быть достигнута более высокая производительность и гибкость, но это слишком неэффективно для большинства разработчиков, мы можем пойти на небольшую жертву производительности в обмен на более высокую эффективность разработки.

Как это решить, добавьте еще один слой, а затем React построил слой VirtualDOM. Мы можем построить дерево объектов декларативно и композиционно и позволить React сопоставить его с DOM:

Сначала отношения между VirtualDOM и DOM были неоднозначными, и они были связаны друг с другом. Позже некоторые люди думали, что у нас есть уровень абстракции VirtualDOM, который должен уметь делать больше, например рендеринг в нативные компоненты на мобильной стороне, PDF, Canvas, пользовательский интерфейс терминала и т. д.

Позже VirtualDOM был более тщательно разделен на уровни.С помощью этого уровня абстракции мы можем сопоставить VirtualDOM с более похожими сценариями приложений:

Следовательно, большее значение VirtualDOM заключается в изменении метода разработки: декларативный, управляемый данными, чтобы разработчикам не нужно было заботиться о деталях работы DOM (операция атрибутов, привязка событий, изменение узла DOM), другими словами , метод разработки изменений приложения сталview=f(state), что значительно способствует высвобождению производительности; кроме того, с уровнем абстракции VirtualDOM возможен многоплатформенный рендеринг.

Конечно, VirtualDOM или React — не единственное и не первое такое решение. Другие интерфейсные фреймворки, такие как Vue и Angular, в основном следуют тому же процессу разработки.

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


Taro

TaroКак и React, они также используют многоуровневый архитектурный стиль, но решают противоположную проблему. React добавляет слой для рендеринга в разные формы представления, в то время как Taro предназначен для унификации различных форм представления.: Сегодня на внутреннем рынке существуют различные формы, такие как Web, React-Native, апплет WeChat... Стоимость написания нескольких наборов кода для разных терминалов очень высока, и этот спрос породил такие фреймворки, как Taro. Рождение .С Taro мы можем написать только один набор кода, который можно вывести на разные терминалы через инструмент компиляции:

(Источник изображения:Многотерминальная унифицированная среда разработки - Taro)



Трубы и фильтры

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

Самый классический случай здесь*unixКоманды оболочки, философия Unix заключается в том, чтобы «делать только одно и делать это хорошо», поэтому функции наших часто используемых команд Unix очень просты, но еще одно волшебное оружие оболочки Unix — каналы, по которым мы можем передавать команды. через标准输入输出Объединены в цепочку для выполнения сложных функций:

# 获取网页，并进行拼写检查。代码来源于wiki
curl "http://en.wikipedia.org/wiki/Pipeline_(Unix)" | \
sed 's/[^a-zA-Z ]/ /g' | \
tr 'A-Z ' 'a-z\n' | \
grep '[a-z]' | \
sort -u | \
comm -23 - /usr/share/dict/words | \
less

Другой пример, похожий на каналы Unix:ReactiveX, НапримерRxJSВо многих туториалах Rx сравнивается с рекой Начало реки — это источник событий, который публикует события с определенной периодичностью. Настоящая сила Rx — это его операторы. С помощью этих операторов вы можетесделать все, что можно сделать, такие как отвод, дросселирование, перекрытие, преобразование, подсчет, слияние, создание рек из рек...

Эти операторы, как и команды Unix, несут единственную ответственность и хорошо выполняют только одну функцию. Но когда мы объединяем их в наших трубопроводах, получается неограниченная мощность.

import { fromEvent } from 'rxjs';
import { throttleTime, map, scan } from 'rxjs/operators';

fromEvent(document, 'click')
  .pipe(
    throttleTime(1000),
    map(event => event.clientX),
    scan((count, clientX) => count + clientX, 0)
  )
  .subscribe(count => console.log(count));

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


Не уверен, что на это повлиял Gulp, современныйWebpackИнструмент упаковки также использует тот же шаблон для обработки файлов, а именноLoader, Загрузчик используется для преобразования исходного кода модуля, благодаря комбинации загрузчика могут быть реализованы сложные требования к переводу файлов.

// webpack.config.js
module.exports = {
  ...
  module: {
    rules: [{
      test: /\.scss$/,
      use: [{
          loader: "style-loader" // 将 JS 字符串生成为 style 节点
      }, {
          loader: "css-loader" // 将 CSS 转化成 CommonJS 模块
      }, {
          loader: "sass-loader" // 将 Sass 编译成 CSS
      }]
    }]
  }
};

ПО промежуточного слоя

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

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

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

  • Журнал: запись времени начала ⏸ расчет времени ответа, вывод журнала запросов
  • Аутентификация: убедитесь, что пользователь вошел в систему
  • Авторизация: убедитесь, что у пользователя есть разрешение на выполнение действия
  • Кэш: есть ли кешированный результат, и если да, вернуть его напрямую ⏸ Когда нижестоящий ответ будет завершен, оцените, можно ли кешировать ответ.
  • Выполнить: выполнить фактическую обработку запроса ⏸ ответ

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

const Koa = require('koa');
const app = new Koa();

// logger

app.use(async (ctx, next) => {
  await next();
  const rt = ctx.response.get('X-Response-Time');
  console.log(`${ctx.method} ${ctx.url} - ${rt}`);
});

// x-response-time

app.use(async (ctx, next) => {
  const start = Date.now();
  await next();
  const ms = Date.now() - start;
  ctx.set('X-Response-Time', `${ms}ms`);
});

// response

app.use(async ctx => {
  ctx.body = 'Hello World';
});

app.listen(3000);

управляемый событиями

управляемый событиями или发布-订阅Стиль — знакомое понятие для фронтенд-разработки.определяет зависимость «один ко многим», В стиле системы, управляемой событиями, компонент не вызывает напрямую другой компонент, а инициирует или передает одно или несколько событий. Другие компоненты в системе регистрируются в одном или нескольких событиях. При срабатывании события система автоматически уведомляет все компоненты, зарегистрированные в этом событии.

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

В жизни много发布-订阅Например, для подписки на информацию об общедоступной учетной записи WeChat, когда добавляется новый подписчик, издателю не нужно вносить какие-либо корректировки, и корректировка издателя не повлияет на подписчика, если соглашение не изменится. мы можем узнать,На самом деле существует ослабленная динамическая связь между издателями и подписчиками..

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

ДНК JavaScript определяет широкое использование шаблонов, управляемых событиями, во внешнем мире.Как работает JavaScript в браузерах и узлах?Кратко описывается принцип выполнения Javascript и упоминается, что JavaScript является однопоточным языком программирования.Чтобы справиться с различными практическими сценариями приложений, поток вообще не может быть занят, а асинхронный метод, управляемый событиями, является спасительная соломинка JavaScript.

Со стороны браузера браузер представляет собой программу с графическим интерфейсом.Программа с графическим интерфейсом представляет собой цикл (более технически называемый циклом событий), который получает пользовательский ввод, обрабатывает программу и затем возвращает обратно на страницу, а затем получает пользовательский ввод...Пользовательский ввод является асинхронным, и абстрагирование пользовательского ввода в события является наиболее кратким, естественным и гибким способом.

Следует отметить, что управление событиями и асинхронность не эквивалентны. Асинхронный !== Управляемый событиями, Управляемый событиями !== Асинхронный

расширять:

  • реактивное программирование: Реактивное программирование также основано на событиях. Ниже приведены два популярных реактивных паттерна в области внешнего интерфейса:
    • 函数响应式(Functional Reactive Programming), обычно представляющий RxJS
    • 透明的函数响应式编程(Transparently applying Functional Reactive Programming - TFRP), обычно представляющий Vue, Mobx
  • шина сообщений: Относится к программной системе, которая получает и отправляет сообщения. Сообщения основаны на известном наборе форматов, поэтому системы могут общаться друг с другом, не зная фактического получателя.

MV*

MV*Также широко используются архитектурные стили. Я думаю, что MV* также по своей сути является многоуровневой архитектурой, в которой также подчеркивается разделение обязанностей. Одним из самых классических является архитектурный стиль MVC, в дополнение к различным производным стилям, таким какMVP,MVVM,MVI(Model View Intent), также несколько связаноFluxилиReduxмодель.


Бытовой МВК

Как следует из названия, MVC делит приложения на три уровня:

  • Слой представления (View) представляет данные пользователю
  • Контроллер (Controller) Связь между моделью и представлением, которая организует разные слои:
    • Обрабатывать события и реагировать. Общие события включают поведение пользователя (например, клики пользователя, запросы клиентов), изменения в слое модели.
    • Контролируйте ход программы. В соответствии с запросом выбирается соответствующая модель для обработки, затем выбирается соответствующий вид для рендеринга и, наконец, предоставляется пользователю.
  • Модель (Model) инкапсулирует данные, связанные с бизнес-логикой приложения и методом обработки данных, обычно ей необходимо взаимодействовать со слоем сохраняемости данных.

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

Вот типичный код AngularJS, слой просмотра:

    <h2>Todo</h2>
    <div ng-controller="TodoListController as todoList">
      <span>{{todoList.remaining()}} of {{todoList.todos.length}} remaining</span>
      [ <a href="" ng-click="todoList.archive()">archive</a> ]
      <ul class="unstyled">
        <li ng-repeat="todo in todoList.todos">
          <label class="checkbox">
            <input type="checkbox" ng-model="todo.done">
            <span class="done-{{todo.done}}">{{todo.text}}</span>
          </label>
        </li>
      </ul>
      <form ng-submit="todoList.addTodo()">
        <input type="text" ng-model="todoList.todoText"  size="30"
               placeholder="add new todo here">
        <input class="btn-primary" type="submit" value="add">
      </form>
    </div>

Логический слой:

angular.module('todoApp', [])
  .controller('TodoListController', function() {
    var todoList = this;
    todoList.todos = [
      {text:'learn AngularJS', done:true},
      {text:'build an AngularJS app', done:false}];

    todoList.addTodo = function() {
      todoList.todos.push({text:todoList.todoText, done:false});
      todoList.todoText = '';
    };

    todoList.remaining = function() {
      var count = 0;
      angular.forEach(todoList.todos, function(todo) {
        count += todo.done ? 0 : 1;
      });
      return count;
    };

    todoList.archive = function() {
      var oldTodos = todoList.todos;
      todoList.todos = [];
      angular.forEach(oldTodos, function(todo) {
        if (!todo.done) todoList.todos.push(todo);
      });
    };
  });

Что касается MVP и MVVM, то в Интернете есть много ресурсов для расширения или апгрейда этих моделей MVC, поэтому я не буду здесь вдаваться в подробности.


Redux

Redux — это усовершенствование архитектуры Flux, включающее в себя функциональные идеи языка Elm.Ниже представлена ​​схема архитектуры Redux:

Из приведенного выше рисунка видно, что архитектура Redux имеет следующие моменты:

  • единый источник данных.
  • односторонний поток данных.

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

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

Вышеупомянутые две функции являются ядром архитектурного стиля Redux.Что касается акцента Redux на неизменяемых данных, использовании промежуточного программного обеспечения для инкапсуляции побочных эффектов и нормализации деревьев состояний, это просто лучшая практика. многое другое类Reduxкаркас, напр.Vuex,ngrx, которые непротиворечивы на уровне архитектурной мысли:


копировать стиль

На основе системы стиля репликации (Replication) несколько экземпляров будут использоваться для предоставления одной и той же услуги, чтобы улучшить доступность и масштабируемость услуги, а также производительность. Этот архитектурный стиль может улучшить воспринимаемую пользователем производительность и уменьшить задержку простых ответов службы.

Этот стиль больше используется в серверной части. Например, NodeJS. NodeJS является однопоточным. Чтобы использовать многоядерные ресурсы, стандартная библиотека NodeJS предоставляетclusterмодуль, который может создавать несколько рабочих процессов в зависимости от количества ЦП. Эти рабочие процессы могут совместно использовать порт сервера и предоставлять однородные услуги внешнему миру. Главный процесс будет выделять ресурсы рабочим в соответствии с определенными политиками:

const cluster = require('cluster');
const http = require('http');
const numCPUs = require('os').cpus().length;

if (cluster.isMaster) {
  console.log(`Master ${process.pid} is running`);

  // Fork workers.
  for (let i = 0; i < numCPUs; i++) {
    cluster.fork();
  }

  cluster.on('exit', (worker, code, signal) => {
    console.log(`worker ${worker.process.pid} died`);
  });
} else {
  // Workers可以共享任意的TCP连接 
  // 比如共享HTTP服务器 
  http.createServer((req, res) => {
    res.writeHead(200);
    res.end('hello world\n');
  }).listen(8000);

  console.log(`Worker ${process.pid} started`);
}

Использование многоядерных возможностей может повысить производительность и надежность приложений. мы также можем использоватьPM2Такой инструмент управления процессами упрощает управление кластерами Node.Он поддерживает множество полезных функций, таких как перезапуск узла кластера, сбор логов и мониторинг производительности.

Стиль репликации часто используется для веб-серверов. И браузер, и Node имеютWorkerконцепции, но обычно рекомендуется использовать их только в сценариях с интенсивным использованием ЦП, потому что браузер или встроенные асинхронные операции NodeJS уже очень эффективны. На самом деле сценариев с интенсивным использованием ЦП для интерфейсных приложений не так много, или на данном этапе это не особенно практично. Кроме того, вы должны взвесить эффективность межпроцессного взаимодействия, сложность управления исполнителями и обработку исключений.

Существует типичный сценарий с интенсивным использованием ЦП, а именно перевод исходного файла.Типичный пример:CodeSandbox, он использует механизм Worker браузера для повышения производительности перевода исходных файлов:

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

Другие примеры:

  • ServerLess

микроядерная архитектура

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

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

Типичный пример в области переднего плана:Webpack,Babel,PostCSSа такжеESLint, Эти приложения должны иметь дело со сложными требованиями к настройке, и эти требования постоянно меняются.Только микроядерная архитектура может гарантировать гибкость и масштабируемость.

Возьмем, к примеру, Webpack. Ядром Webpack является компилятор, основная функция которого — интегрировать систему плагинов, поддерживать模块对象图, Конкретная компиляция кода модуля, упаковка модуля, оптимизация, анализ и агрегирование выполняются на основе внешних подключаемых модулей.

Как было сказано выше, Loader использует режим конвейера и отвечает за трансляцию исходных файлов; Plugin может внедрять поведение в хуки всего жизненного цикла работы Compiler, и полностью получать доступ к текущему состоянию Compiler.

Sean LarkinЕсть речь:Everything is a plugin! Mastering webpack from the inside out


Вот еще одна статьяСпециально написал некоторые приложения режима фронтальной микроядерной архитектуры, рекомендуется к прочтению.


микро интерфейс

Я слышал это несколько дней назадвремя коданачальстволевое ухо крысапервый выпускпрограмма, Он рассказал, что в Amazon есть много небольших команд. Область размером с кусок тофу на веб-сайте Amazon может поддерживаться командой, например, селекторами адресов, корзинами покупок и расчетами времени доставки... супер проект Дачанга Как координировать и поддерживать его? Это может быть причиной появления микрофронтендов или микросервисов.

Микрофронтенды предназначены для单体前端Разбивайте на более мелкие и простые модули, которые могут разрабатываться, тестироваться и развертываться независимыми командами, а затем объединяться в единое целое.

Каждый модуль приложения под микро-фронтендом работает самостоятельно, развивается и развертывается самостоятельно, соответственно, он будет оснащен более автономной командой (одна команда делает одно дело хорошо). Реализация микроинтерфейса также требует поддержки надежной инфраструктуры интерфейса и системы исследований и разработок.

Если вы хотите подробно изучить архитектуру микрофронтенда, рекомендуется прочитатьPhodalизСтатьи по Темеи его новая книга«Внешняя архитектура: от начала до микро-интерфейсов»


Компонентная архитектура

Разработка компонентов так же естественна для нас сегодня, как вода для рыб. Таким образом, мы забываем, что компонентизация также является очень важной архитектурной идеей, и ее основная идея заключается в том, чтобы разделять и властвовать. Согласно приведенному выше определению в Вики:组件化就是基于可复用目的，将一个大的软件系统按照分离关注点的形式，拆分成多个独立的组件，主要目的就是减少耦合.

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

(Источник изображения:woohoo.alloy team.com/2015/11/башня-…)

Согласно официальному сайту Vue:组件系统是 Vue 的另一个重要概念，因为它是一种抽象，允许我们使用小型、独立和通常可复用的组件构建大型应用。仔细想想，几乎任意类型的应用界面都可以抽象为一个组件树:

насколько я понимаюКомпоненты — это то же самое, что и функции, поэтому идеи функционального программирования так естественно применимы в React.. Несколько простых функций могут быть объединены в сложные функции, а сложные функции могут быть объединены в сложные приложения. Для внешнего интерфейса страница также выглядит так: сложная страница состоит из компонентов с разной степенью детализации.

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


разное

я больше не могу писать! Также существует множество архитектурных стилей, которые ограничены размером статьи, и эти стили в основном используются в области бэкенда, поэтому я не буду описывать их здесь по одному. ты можешь пройти扩展阅读Узнайте об этих шаблонах

  • объектно-ориентированный стиль: Разделите задачи приложения или системы на отдельные повторно используемые автономные объекты, каждый из которых содержит данные и поведение, связанное с объектом.
  • C/S стиль клиент/сервер
  • Сервис-ориентированная архитектура (SOA): Относится к тем приложениям, которые используют контракты и сообщения для представления функций как сервисов и использования функциональных сервисов.
  • N слой / три слоя: Подобно многоуровневой архитектуре, основное внимание уделяется физическому уровню. Например, стиль C/S представляет собой типичную N-уровневую архитектуру.
  • точечный стиль

Благодаря вышеизложенному вы можете почувствовать, что архитектурный стиль гораздо легче понять, чем шаблон проектирования или алгоритм.Авеню к Джейн',но'Лаконично, но не просто'! Архитектура большинства проектов изначально не такая, они могут быть такими, какие они есть сегодня, после долгих итераций, наступая на плечи гигантов и идя по пути.

Я надеюсь, что эта статья может дать вам немного вдохновения.Для наших фронтенд-инженеров мы должны не только заниматься тем, как можно сделать крутые страницы и сколько API мы можем освоить, мы должны научиться видеть суть через явления и делать выводы из друг друга. Это путь к продвижению.

В статье есть ошибки, прокомментируйте

Эта статья закончилась!


Расширенное чтение


Категории