Предисловие
В последние годы многоцелевая адаптация различных сайтов на основе веб-сайта была в полном разгаре, и решения, основанные на различных технологиях, также были разработаны среди отраслей. Такие как отзывчивый дизайн, основанный на нативном Media запросе CSS3 браузера, решение «облачная адаптация», основанное на повседневном уборке облаков и т. Д.
О фронтальном разделении
Что касается решения фронтального разделения, то есть очень четкое объяснение в «Мышлении и практике разделения фронта, основанной на Nodejs (i)». Мы представили Nodejs в качестве уровня рендеринга между интерфейсом сервера и браузером. Поскольку слой Nodejs полностью отделен от данных и не нуждается в заботе о большой бизнес-логике, он очень подходит для многопользовательской адаптационной работы на этом уровне.
UA обнаружение
Первое, что нужно решить в многопользованной адаптации,-это проблема обнаружения UA. Для запроса нам необходимо знать тип этого устройства для вывода соответствующего контента. В настоящее время существуют очень зрелые библиотеки функций пользовательского агента и инструменты обнаружения, совместимые с большим количеством устройств на рынке. Вот список, составленный Mozilla. Среди них есть как те, которые работают на стороне браузера, так и те, которые работают на уровне кода на стороне сервера. Некоторые инструменты даже предоставляют модули Nginx/Apache, которые отвечают за анализ информации UA для каждого запроса.
На самом деле мы рекомендуем последний. Решение, основанное на разделении переднего конца, определяет, что зонд UA может работать только на стороне сервера, но это не достаточно удобное решение, если код зонда и библиотеки функций связаны в бизнес-коде. Мы перемещаем это поведение вперед и вешаем его на Nginx/Apache. Они несут ответственность за анализ информации UA для каждого запроса, а затем передавать ее в бизнес -код через заголовок HTTP.
Есть несколько преимуществ, чтобы сделать это:
Наш код больше не должен обращать внимание на то, как UA анализируется, просто выньте анализируемую информацию из верхнего уровня. Если на одном и том же сервере есть несколько приложений, информация UA, проанализированная одним и тем же NGINX, может использоваться вместе, сохраняя потерю разрешения между различными приложениями.
Решение для обнаружения UA на основе Nginx, разделяемого TMALL
Веб -сервер Tangine от Taobao также предоставляет аналогичный модуль ngx_http_user_agent_module.
Стоит отметить, что при выборе инструментов обнаружения UA необходимо рассмотреть учебную библиотеку. Поскольку на рынке все больше и больше новых типов оборудования, каждое устройство будет иметь независимый пользовательский агент, поэтому библиотека функций должна предоставлять хорошие стратегии обновления и технического обслуживания для адаптации к изменяющемуся оборудованию.
Несколько адаптаций, встроенных в режим MVC
После получения информации UA мы должны рассмотреть, выполняется ли адаптация терминала на основе указанного UA. Даже в слое Nodejs, хотя большая часть бизнес -логики отсутствует, мы все равно разделим внутренние модели: модель/контроллер/представление.
Давайте сначала используем приведенную выше диаграмму для анализа некоторых существующих многоцелевых решений для адаптации.
Адаптации, построенные на контроллере
Это решение должно быть самым простым и самым грубым способом справиться с ним. Передайте тот же URL к тому же контрольному слою через маршрутизатор. Затем контрольный уровень распространяет данные и логику модели на соответствующий дисплей (представление) через информацию UA для рендеринга, а слой рендеринга предоставляет шаблоны, которые адаптируются к нескольким терминалам в соответствии с предварительными конвенциями.
Преимущество этого решения состоит в том, что оно поддерживает единство данных и контрольных слоев, а бизнес -логика может применяться ко всем терминалам только один раз. Тем не менее, этот сценарий подходит только для низкоинтерактивных приложений, таких как страницы дисплея. Как только бизнес станет более сложным, контроллеры каждого терминала могут иметь свою собственную логику обработки. Если они по -прежнему разделяют контроллер, это сделает контроллер очень раздутым и трудным для поддержания, что, несомненно, является неправильным выбором.
Адаптации, построенные на маршрутизаторе
Чтобы решить вышеуказанные проблемы, мы можем различить устройства на маршрутизаторе и распространять их на разные контроллеры для разных терминалов:
Это также одно из наиболее распространенных решений, в основном проявляющихся в использовании отдельного набора приложений для разных терминалов. Например, когда домашняя страница Taobao Taobao и версия WAP на домашней странице Taobao, когда разные устройства посещают www.taobao.com, сервер будет перенаправлен на версию Homepage Taobao или версию PC Taobao HomePage через управление маршрутизатором. Это два совершенно независимых набора приложений.
Тем не менее, это решение, несомненно, вызывает проблему, что данные и часть логики не могут быть переданы. Различные терминалы не могут делиться одними и теми же данными и бизнес -логикой, что приводит к большой повторяющейся работе и неэффективна.
Чтобы решить эту проблему, кто -то предложил оптимизированное решение: в одном и том же наборе приложений каждый источник данных все еще абстрагируется в каждую модель и предоставляется контроллерам различных терминалов для комбинации:
Это решение решает проблему, что предыдущие данные не могут быть переданы. На контроллере каждый терминал все еще не зависит друг от друга, но может вместе использовать одну и ту же партию источников данных. По крайней мере, нет необходимости разрабатывать независимые интерфейсы для типов терминалов в данных.
В двух вышеуказанных решениях на основе маршрутизатора, из-за независимости контроллера, каждый терминал может реализовать различную интерактивную логику для своих страниц, обеспечивая достаточную гибкость для каждого самого терминала, что также является основной причиной, по которой большинство приложений принимают это решение.
Адаптации, построенные на слое вида
Это решение, используемое для страниц заказа Taobao, но разница в том, что страница упорядочения помещает общий слой рендеринга со стороны браузера, а не слой Nodejs. Однако, будь то браузер или Nodejs, общая идея дизайна все же:
В этом решении маршрутизатор, контроллер и модель не должны обращать внимание на информацию об устройстве, а суждение типа терминала полностью оставлено на уровне дисплея для обработки. Основным модулем на рисунке является «Посмотреть завод». После того, как модель и контроллер передают логику данных и рендеринга, они используют заводскую завод для получения определенных компонентов из кучи заданных компонентов на основе информации об устройстве и других состояниях (не только информации UA, но и сетевой среды, области пользователя и т. Д.), А затем объединяют их в окончательную страницу.
Это решение имеет несколько преимуществ:
Верхний слой не должен обращать внимание на информацию об устройстве (UA). Видео с несколькими терминалами все еще обрабатываются слоем представления, который в конечном итоге показывает наибольшие отношения. Это не просто многопользовательская адаптация, но в дополнение к информации UA, каждый компонент представления также может определить, какой шаблон он выводит в соответствии со статусом пользователя, такими как скрытие изображений по умолчанию на низких скоростях сети и выводы баннеров активности в назначенных областях. Различные шаблоны каждого компонента представления могут решить, использовать ли одни и те же данные и бизнес -логику по своему усмотрению, предоставляя очень гибкий метод реализации.
Но очевидно, что это решение также является наиболее сложным, особенно при рассмотрении некоторых интерактивных сценариев применения, маршрутизатор и контроллер могут не оставаться такими чистыми. Особенно для некоторых предприятий с относительно сильной целостностью, которые не могут быть разделены на сами компоненты, это решение может быть не применимо; А для некоторых простых предприятий использование этой архитектуры может быть не лучшим выбором.
Суммировать
Вышеуказанные решения отражаются в одной или нескольких частях модели MVC. Если одно решение не отвечает потребностям в бизнесе, могут быть приняты несколько решений одновременно. Или можно понять, что сложность и интерактивные атрибуты в бизнесе определяют, какое многоцелевое решение адаптации для продукта более подходит.
По сравнению с схемой адаптивной проектирования на основе браузера, потому что большая часть обнаружения терминалов и логики рендеринга перенесена на сервер, адаптируясь на уровне Nodejs, несомненно, обеспечивает лучшую производительность и пользовательский опыт; Кроме того, по сравнению с проблемами качества конверсии, вызванными некоторыми так называемыми схемами «облачной адаптации», они не будут существовать в «индивидуальной» схеме, основанной на разделении фронта. Решение адаптации для разделения передних и задних концов имеет естественные преимущества в этих аспектах.
Наконец, чтобы адаптироваться к более гибким и мощным потребностям адаптации, решения адаптации, основанные на разделении, будут столкнуться с большим количеством проблем!