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

1. Предпосылки

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

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

Таким образом, хорошее многоуровневое приложение должно иметь следующие моменты:

Это удобно для последующего сопровождения и расширения кода.
Эффект многослойности должен быть принят всей командой
Четкие обязанности для каждого уровня

2. Как наслаивать

2.1 Технические характеристики Али

Уровни ограничений в спецификации кодирования Али следующие:

Уровень открытого интерфейса: он может напрямую инкапсулировать метод службы и предоставлять его как интерфейс RPC; инкапсулировать его в http-интерфейс через Интернет; выполнять контроль безопасности шлюза, управление потоком и т. д.

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

Веб-уровень: в основном для переадресации управления доступом, проверки различных основных параметров или просто обработки немультиплексированных сервисов.

Сервисный уровень: относительно специфичный сервисный уровень бизнес-логики.

Уровень менеджера: общий уровень бизнес-обработки, он имеет следующие характеристики: 1. Уровень, который инкапсулирует стороннюю платформу, выполняет предварительную обработку возвращаемых результатов и преобразовывает информацию об исключениях, 2. Использование общих возможностей уровня службы, таких как решения для кэширования, общая обработка промежуточного программного обеспечения 3. Взаимодействие со слоем DAO для повторного использования комбинации нескольких DAO.

Уровень DAO: уровень доступа к данным, который взаимодействует с базовыми MySQL, Oracle и Hbase.

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

2.2 Оптимизация слоев

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

1. Контроллер верхнего уровня и TService — это первые уровни в нашей многоуровневой спецификации Alibaba: простая бизнес-логика, проверка параметров и исключения. Обычно такой интерфейс может легко изменить тип интерфейса, поэтому бизнес-логика должна быть легкой или вообще не иметь конкретной логики.

2. Сервис: бизнес-уровень имеет низкую возможность повторного использования. Рекомендуется, чтобы каждый метод контроллера соответствовал сервису. Не устраивайте бизнес в контроллере. Почему? Если мы организуем деловое соглашение на уровне контроллера, если мы хотим получить доступ к бережливости в будущем, нам нужно снова организовать деловое соглашение, что заставит нас копировать код каждый раз, когда мы обращаемся к начальному уровню, как показано ниже. :

Такой большой объем повторяющейся работы однозначно приведет к снижению эффективности нашей разработки, поэтому нам нужно заложить в сервис логику бизнес-оркестровки, чтобы он делал:

3. Менеджер: многоразовый логический уровень. Менеджер здесь может быть отдельной службой, такой как наш кеш, mq и т. д., конечно, он также может быть составным, когда вам нужно вызвать несколько менеджеров, это можно объединить в менеджер, например таблицу логических соединений. запрос и т.п. Если это httpMannager или rpcMannager, на этом уровне необходимо выполнить некоторое преобразование данных.

4. DAO: уровень доступа к базе данных. В основном отвечает за «управление таблицей в базе данных и сопоставление ее с java-объектом», dao должен разрешать доступ только своей собственной службе, другие службы должны получать доступ к моим данным через соответствующую службу.

3. Преобразование иерархической модели предметной области

Следующие спецификации модели предметной области перечислены в спецификациях кодирования Alibaba:

DO (объект данных): однозначное соответствие со структурой таблицы базы данных, и объект источника данных передается вверх через уровень DAO.
DTO (Объект передачи данных): Объект передачи данных, объект, который Служба или Менеджер передает наружу.
BO (Бизнес-объект): бизнес-объект. Объекты, которые инкапсулируют выходные данные бизнес-логики уровня службы.
АО (объект приложения): объект приложения. Абстрактная повторно используемая объектная модель между веб-уровнем и сервисным уровнем очень близка к уровню отображения, и степень повторного использования невелика.
VO (Объект просмотра): Объект слоя отображения, обычно объект, передаваемый из Интернета на уровень механизма рендеринга шаблона.
Запрос: объект запроса данных, каждый уровень получает запрос запроса от верхнего уровня. Обратите внимание, что при инкапсуляции запроса с более чем двумя параметрами запрещается использовать класс Map для передачи.

уровень	доменная модель
Controller/TService	VO/DTO
Service/Manager	AO/BO
DAO	DO

Каждый уровень в основном имеет свою собственную соответствующую модель домена, что приводит к тому, что некоторые люди используют каждый уровень со своей собственной моделью домена, что приводит к объекту, который может быть преобразован 3 или даже 4 раза за один запрос.Также будет 3-4 преобразования при возврате, поэтому вполне возможно, что полный запрос-возврат будет иметь много преобразований объектов. Если вы действительно следите за этим в разработке, я боюсь не писать другие вещи, просто написать эту повторяющуюся и бесполезную логику на день.

Так что приходится идти на компромисс:

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

2. Не допускается передача модели предметной области уровня Controller/TService на уровень DAO, что не соответствует разделению ответственности.

3. Точно так же данные с уровня DAO не могут быть переданы в Controller/TService.

4. Резюме

В целом, бизнес-слои важнее для спецификации кода, которая определяет, можно ли повторно использовать код в будущем, ясны ли обязанности и границы.

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

Наконец, если у вашей команды есть лучшие слои или если приведенное выше описание неверно, оставьте комментарий и исправьте его.

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

Наконец, эта статья была включена в JGrowing, всеобъемлющий и отличный маршрут изучения Java, совместно созданный сообществом. Если вы хотите участвовать в обслуживании проектов с открытым исходным кодом, вы можете создать его вместе. Адрес github: https:// github.com/javagrowing/JGrowing Пожалуйста, дайте мне маленькую звезду.