Автор: кофе латте
Слои кода должны быть знакомы любому Java-разработчику. Хорошее иерархическое разделение может не только сделать структуру кода более понятной, но и сделать разделение проекта более четким, значительно улучшить читаемость и облегчить последующее обслуживание и обновление.
С другой точки зрения, хорошая многоуровневая архитектура кода должна хорошо соответствовать принципу единой ответственности. Таким образом, зависимости между уровнями могут быть уменьшены, а логика каждого уровня может быть повторно использована в максимально возможной степени. В этой статье будет показано, как код проекта Java должен быть многоуровневым.
1. Предпосылки
Когда дело доходит до многоуровневого приложения, большинство людей думают, что это не очень просто, всего три уровня контроллера, сервиса и картографа. Это кажется простым, но многие люди на самом деле не разделяют свои обязанности.Во многих кодах контроллер выполняет больше логики, чем служба, и служба часто рассматривается как прозрачная передача.Это на самом деле место, которое многие люди не замечают при разработке В любом случае, функцию можно использовать, куда бы вы ее ни поместили. Это часто приводит к тому, что последующий код становится непригодным для использования, иерархические отношения становятся хаотичными, а сопровождение последующего кода становится очень проблематичным.
Ведь в глазах этих людей расслоение — это просто форма, так написан код предшественников, так написан код других проектов, поэтому я тоже так пишу. Однако в реальной командной разработке привычки у всех разные, и написанный код должен иметь свою метку.Кто-то привык, что контроллер пишет много бизнес-логики, а кто-то привык вызывать удаленные сервисы между сервисами, чтобы В результате стиль разработки кода у всех совершенно разный. Когда другие люди модифицируют его позже, на первый взгляд, код, который я полагаюсь на этого человека в написании, полностью отличается от моих обычных привычек. , Как только выбор предвзят, когда ваши младшие поддерживают ваш код, я боюсь, что они будут ругаться.
Таким образом, хорошее многоуровневое приложение должно иметь следующие моменты:
- Это удобно для последующего сопровождения и расширения кода.
- Эффект многослойности должен быть принят всей командой
- Четкие обязанности для каждого уровня
2. Как наслаивать
2.1 Технические характеристики Али
Уровни ограничений в спецификации кодирования Али следующие:
Уровень открытого интерфейса: он может напрямую инкапсулировать метод службы и предоставлять его как интерфейс RPC; инкапсулировать его в http-интерфейс через Интернет; выполнять контроль безопасности шлюза, управление потоком и т. д.
Слой отображения терминала: слой, на котором шаблоны на каждой стороне отображают и выполняют отображение. В настоящее время это в основном рендеринг скорости, рендеринг JS, рендеринг JSP, мобильный дисплей и т. д.
Веб-уровень: в основном для переадресации управления доступом, проверки различных основных параметров или просто обработки немультиплексированных сервисов.
Сервисный уровень: относительно специфичный сервисный уровень бизнес-логики.
Уровень менеджера: общий уровень бизнес-обработки, он имеет следующие характеристики: 1. Уровень, который инкапсулирует стороннюю платформу, предварительно обрабатывая возвращаемые результаты и преобразовывая информацию об исключениях, 2. Использование общих возможностей уровня службы, таких как решения для кэширования, общая обработка промежуточного программного обеспечения 3. Взаимодействие со слоем DAO для повторного использования комбинации нескольких DAO.
Уровень DAO: уровень доступа к данным, который взаимодействует с базовыми MySQL, Oracle и Hbase.
Слои в протоколе Alibaba относительно ясны и просты, но описание по-прежнему слишком простое, и многие студенты на уровне обслуживания и уровне менеджера все еще немного не понимают взаимосвязь между ними, что приводит к множеству проектов. Уровень менеджера вообще отсутствует. Ниже описано, как реализовать многоуровневость в конкретном бизнесе.
2.2 Оптимизация слоев
Относительно идеальная модель резюмируется из нашего развития бизнеса.Здесь мы должны сначала объяснить, что, поскольку наша структура rpc использует бережливость, она может иметь на один уровень больше, чем другие среды rpc, такие как dubbo, и ее функции аналогичны уровню контроллера.
Контроллер верхнего уровня и TService — это первые уровни в нашей многоуровневой спецификации Alibaba: легкая бизнес-логика, проверка параметров и исключения. Обычно такой интерфейс может легко изменить тип интерфейса, поэтому бизнес-логика должна быть легкой или вообще не иметь конкретной логики.
Служба: бизнес-уровень имеет низкую возможность повторного использования.Рекомендуется, чтобы каждый метод контроллера соответствовал службе.Не устраивайте бизнес в контроллере.Почему? Если мы организуем деловое соглашение на уровне контроллера, если мы хотим получить доступ к бережливости в будущем, нам нужно снова организовать деловое соглашение здесь, что заставит нас копировать код каждый раз, когда мы обращаемся к начальному уровню, как показано ниже. :
Такой большой объем повторяющейся работы однозначно приведет к снижению эффективности нашей разработки, поэтому нам необходимо заложить в сервис логику бизнес-оркестровки, чтобы:
Mannager: многоразовый логический слой. Менеджер здесь может быть отдельной службой, такой как наш кеш, mq и т. д., конечно, он также может быть составным, когда вам нужно вызвать несколько менеджеров, это можно объединить в менеджер, например таблицу логических соединений. запрос и т.п. Если это httpMannager или rpcMannager, на этом уровне необходимо выполнить некоторое преобразование данных.
DAO: Уровень доступа к базе данных. В основном отвечает за «управление таблицей в базе данных и сопоставление ее с java-объектом», dao должен разрешать доступ только своей собственной службе, другие службы должны получать доступ к моим данным через соответствующую службу.
3. Преобразование иерархической модели предметной области
Следующие спецификации модели предметной области перечислены в спецификациях кодирования Alibaba:
- DO (объект данных): однозначное соответствие со структурой таблицы базы данных, и объект источника данных передается вверх через уровень DAO.
- DTO (Объект передачи данных): Объект передачи данных, объект, который Служба или Менеджер передает наружу.
- BO (Бизнес-объект): бизнес-объект. Объекты, которые инкапсулируют выходные данные бизнес-логики уровня службы.
- АО (объект приложения): объект приложения. Абстрактная повторно используемая объектная модель между веб-уровнем и сервисным уровнем очень близка к уровню отображения, и степень повторного использования невелика.
- VO (Объект просмотра): Объект слоя отображения, обычно объект, передаваемый из Интернета на уровень механизма рендеринга шаблона.
- Запрос: объект запроса данных, каждый уровень получает запрос запроса от верхнего уровня. Обратите внимание, что при инкапсуляции запроса с более чем двумя параметрами запрещается использовать класс Map для передачи.
Контроллер модели иерархического домена/TServiceVO/DTOService/ManagerAO/BODAODO
Каждый уровень в основном имеет свою собственную соответствующую модель домена, что приводит к тому, что некоторые люди используют каждый уровень со своей собственной моделью домена, что приводит к объекту, который может быть преобразован 3 или даже 4 раза за один запрос.Также будет 3-4 преобразования при возврате, поэтому вполне возможно, что полный запрос-возврат будет иметь много преобразований объектов. Если вы действительно следите за этим в разработке, я боюсь не писать другие вещи, просто написать эту повторяющуюся и бесполезную логику на день.
Так что приходится идти на компромисс:
1. Разрешить службе/менеджеру управлять моделью предметной области.Для этого уровня работа, которая изначально выполняется им самим, также включает обработку бизнес-логики и сборку данных.
2. Не допускается передача модели предметной области уровня Controller/TService на уровень DAO, что не соответствует разделению ответственности.
3. Точно так же данные с уровня DAO не могут быть переданы в Controller/TService.
4. Резюме
В целом, бизнес-слои важнее для спецификации кода, которая определяет, можно ли повторно использовать код в будущем, ясны ли обязанности и границы.
Конечно, такая стратификация на самом деле является вопросом мнения, и у каждого в команде разные привычки к стратификации, поэтому сложно взвесить стандартный критерий. обслуживание легкое, это хорошая стратификация.
Наконец, если у вашей команды есть лучшие слои или если приведенное выше описание неверно, оставьте комментарий и исправьте его.
Приветствую всех желающих пообщаться с вами.Если вам понравилась статья, не забудьте поставить лайк.Спасибо за вашу поддержку!