Оригинальный адрес:Блог Лян Гуйчжао
адрес блога:blog.720ui.com
Добро пожаловать в перепечатку, пожалуйста, указывайте автора и источник, спасибо!
Идея многоуровневости является наиболее распространенным архитектурным паттерном прикладных систем.Мы разрежем систему по горизонтали и разделим ее в соответствии с бизнес-обязанностями. Трехуровневая архитектура MVC является очень типичным архитектурным шаблоном.Цель разделения состоит в том, чтобы спланировать логическую структуру программной системы для облегчения разработки и обслуживания. MVC: модель-представление-контроллер на английском языке, который разделен на уровень модели, уровень представления и уровень управления. Отдельные страницы и бизнес-логика для повышения масштабируемости и удобства обслуживания приложения. как показано на рисунке.
На самом деле трехуровневая архитектура MVC — это лишь руководящая идеология на концептуальном уровне, и мы разобьем иерархию более подробно. Например, шаблон MVC традиционной серверной части размыт для разграничения клиентской части и серверной части. При нормальных обстоятельствах разработчики внешнего интерфейса несут ответственность за написание статических страниц проекта, включая HTML-страницы, стили CSS и интерактивные части JavaScript, и предоставляют их разработчикам на стороне сервера для написания сервисов уровня представления, и даже некоторые проекты напрямую позволяют фронтенд-разработчики для завершения уровня представления.Задачи развития бизнеса. Проблема, вызванная этим режимом разработки, заключается в том, что в процессе разработки нет четкого разделения фронтенда и бэкенда, и существует сильная взаимная зависимость Разработчики фронтенда должны заботиться о бизнесе сервера, а разработчики серверов также нужно полагаться на прогресс фронт-энда. А с добавлением нескольких клиентов, таких как Android, IOS, ПК и U3D, стоимость разработки и обслуживания программы будет увеличиваться в геометрической прогрессии. Чтобы повысить эффективность разработки и уточнить обязанности, все больше внимания уделяется необходимости разделения клиентской и серверной частей. Разделение внешнего интерфейса и внутреннего интерфейса заключается в том, что сервер предоставляет интерфейс API, а внешний интерфейс вызывает AJAX для реализации взаимодействия с данными. как показано на рисунке.
Кроме того, с постоянным расширением возможностей хранения данных (MySQL, Oracle, Redis, MongoDB, ElasticSearch, PostgreSQL, HBase и т. д.), а также с ростом популярности микросервисов мы часто полагаемся на RPC (Dubbo, HSF, Thrift). и т. д.) Многие внешние интерфейсы или HTTP-вызовы сторонних платформ. Поэтому нам нужна мелко разделенная структура кода. Кроме того, много раз мы не разделяли их обязанности в процессе разработки. Например, в структуре кода мы помещаем много логического бизнеса на уровень контроллера и используем только сервис как способ прозрачной передачи данных. На самом деле это неправильно. По совпадению мы также обнаружим, что некоторые проекты вызывают удаленные службы на уровне Dao, а некоторые будут выполнять такие операции на уровне службы или уровне контроллера.Из-за различных привычек разных студентов-исследователей или взлома стиль кода разработки совершенно другое.Иерархия кода перепуталась.
Подводя итог, можно сказать, что трехуровневая архитектура MVC является лишь направляющей идеологией на концептуальном уровне, и мы разберем иерархию более подробно. Теперь углубимся в"Как разумно проектировать многоуровневый код, о методе проектирования многоуровневого кода". На мой взгляд, разумное наслоение кода должно быть таким. Как показано на рисунке.
Так,слой бизнес-логикиВ его обязанности входит взаимодействие с __уровнем сохраняемости данных__, объединение операций нескольких источников данных и предоставление возможности их объединения и повторного использования. Кроме того, это также уровень обработки общих бизнес-возможностей, включая решения для кэширования, мониторинг сообщений (MQ), синхронизированные задачи и многое другое. Кроме того, мы должны поместить как можно больше бизнес-процессов на уровень __бизнес-логики__, включая проверку параметров, преобразование данных, обработку исключений и т. д., вместо того, чтобы обрабатывать их в контроллере.
Автор считает, что уровень обработки запросов имеет три возможности: одна — рендеринг через механизм шаблонов, такой как рендеринг страниц FreeMarket и Velocity, и HTTP-интерфейс RESTful API, инкапсулированный слоем контроллера. Если в проекте используются RPC-сервисы, такие как Dubbo, HSF, Thrift и т. д., нам также необходимо предоставить соответствующие сервисы вышестоящим бизнес-сторонам, которые реализованы через Service и представлены в виде RPC-интерфейсов. Здесь наименование Сервиса относительное, как правило, интерфейс предоставляется через Клиент, а конкретная бизнес-логика реализуется через Сервис.
Логическую структуру мы понимаем, значит, автор считает, что относительно четкая физическая структура кода должна быть такой.
Итак, можем ли мы вызывать через слои? Автор считает, что нужно запретить межуровневые вызовы, потому что каждый уровень имеет свои обязанности и прозрачен для верхнего уровня, точно так же, как модель семиуровневого протокола OSI и модель четырехуровневого протокола TCP/IP, только обязанности ограничены В пределах своих границ, общая иерархия ясна. Тогда для одноуровневого вызова автор считает, что это разрешено на уровне бизнес-логики, но особое внимание следует уделить генерации циклических вызовов.
Теперь разберем несколько доменных моделей по горизонтали: VO, BO, DO, DTO. Эта концепция упоминается в Спецификации кодирования Ali.Из-за сложности бизнеса эти концепции предлагаются для лучшего моделирования предметной области и изоляции модели. Среди них DO (объект данных) соответствует структуре таблицы базы данных один за другим, а объект источника данных передается вверх через уровень DAO. DTO (объект передачи данных) — это объект удаленного вызова, представляющий собой модель предметной области, предоставляемую службой RPC. Обратите внимание, что DTO должен быть сериализован, реализовывать интерфейс Serializable и предоставлять serialVersionUID, иначе во время десериализации, если serialVersionUID изменен, десериализация завершится ошибкой. На самом деле единственная разница между DO и DTO заключается в том, что одна из них представляет собой доменную модель локального источника данных, а другая — сериализованную доменную модель удаленной службы. Для BO (бизнес-объект) это объект, который инкапсулирует бизнес-логику на уровне бизнес-логики.В общем, это составной объект, объединяющий несколько источников данных. Затем VO (View Object) обычно является объектом, передаваемым уровнем обработки запросов.После того, как он преобразуется платформой Spring, он часто является объектом JSON. Например, если вам нужно решить проблему потери точности данных типа Long (при прямой передаче на веб-сторону точность будет теряться, когда длина Long будет больше 17 цифр), вы можете автоматически преобразовывать возвращенные данные в @ResponseBody на уровне контроллера. Когда JSON, он единообразно инкапсулируется в строку.
Подводя итог, многоуровневая идея разрезает систему по горизонтали и делит ее в соответствии с бизнес-обязанностями. Целью разделения является планирование логической структуры программной системы для облегчения разработки и обслуживания. Однако с развитием микросервисов и привычек кодирования различных исследований и разработок это часто приводит к неполному распределению кода и появлению «неприятных запахов». Автор пытается выдвинуть новую идею многоуровневого кода, чтобы избежать и стандартизировать эту многоуровневую структуру.
Если у вас есть другие идеи и интересы, добавьте меня в WeChat для обсуждения и общения~
(Конец, перепечатка с указанием автора и источника.)
Еще больше интересных статей в разделе «Серверное мышление»!