Слои кода должны быть знакомы любому веб-разработчику Java. Хорошее иерархическое разделение может не только сделать структуру кода более понятной, но и сделать разделение проекта более четким, значительно улучшить читаемость и облегчить последующее обслуживание и обновление.
С другой точки зрения, хорошая многоуровневая архитектура кода должна хорошо соответствовать принципу единой ответственности. Таким образом, зависимости между уровнями могут быть уменьшены, а логика каждого уровня может быть повторно использована в максимально возможной степени. В этой статье будет показано, как должен быть разделен код веб-проекта Java.
Трехуровневая архитектура
В проектировании архитектуры программного обеспечения многоуровневая структура является наиболее распространенной и наиболее важной. Иерархическая структура, рекомендованная Microsoft, обычно делится на три уровня снизу вверх: уровень доступа к данным, уровень бизнес-логики (также называемый уровнем предметной области) и уровень представления. Это также три уровня в трехуровневой архитектуре, которая важна для Java Web. Целью различения слоев является идея «высокой сплоченности и низкой связанности».
Так называемая трехуровневая архитектура представляет собой «средний уровень», также называемый компонентным уровнем, между клиентом и базой данных. Упомянутая здесь трехуровневая система не относится к физической трехуровневой системе.Это не просто размещение трех машин или трехуровневая архитектура.Трехуровневая архитектура представляет собой не только приложение B/S. Трехуровневая система относится к логическим трем слоям, то есть три слоя размещаются на одной машине.
уровень доступа к данным
В основном это операционный уровень неоригинальных данных (база данных или текстовый файл и т. д.), а не исходные данные, то есть работа с базой данных, а не с данными, особенно для уровня бизнес-логики или уровня представления. служба данных.
слой бизнес-логики
Это в основном для работы с конкретными проблемами, и его также можно понимать как работу уровня данных и бизнес-логику обработки данных.Если уровень данных является строительным блоком, то уровень логики представляет собой построение этих зданий блоки.
интерфейсный слой
В основном представляет метод WEB. Если уровень логики достаточно мощный и полный, независимо от того, как определяется и изменяется уровень представления, уровень логики может предоставлять услуги в полном объеме.
Разница между трехуровневой архитектурой и MVC
MVC (Model-View-View-Controller Controller) — это архитектурный шаблон, который можно использовать для создания различия между объектами предметной области и объектами уровня представления пользовательского интерфейса.
То же самое на архитектурном уровне, то же самое, что у них есть слой представления, но они разные в двух других слоях.
Концепция контроллера не определена в трехуровневой архитектуре. Это самое разное место. И MVC не рассматривает логический доступ бизнеса как два уровня, что является основным отличием между использованием трехуровневой архитектуры или MVC для построения программы.
более детальное наслоение
С постоянным увеличением числа пользователей веб-сайта архитектура системы также постоянно корректируется. Иногда по мере того, как бизнес становится все более и более сложным, иногда трехуровневая архитектура кажется недостаточной. Например, в дополнение к предоставлению пользователям доступа к странице наше приложение также должно предоставлять некоторые открытые интерфейсы для внешних системных вызовов. Этот интерфейс не относится ни к интерфейсному слою, ни к слою бизнес-логики, поскольку он также может содержать некоторую обработку, не связанную с бизнес-логикой, такую как управление разрешениями, управление потоком и т. д.
Кроме того, с преобладанием микросервисов наши приложения могут зависеть от многих внешних интерфейсов или сторонних платформ. Эта часть кода не подходит для описания уровня бизнес-логики и уровня доступа к данным.
Поэтому постепенно на основе трехуровневой архитектуры усложняется многоуровневость архитектуры системы. Именно из-за сложности он проверяет способность проектирования архитектуры.Поскольку разделение уровней не очень хорошо, оно может повлиять на последующую разработку и создать большие трудности для обслуживания кода.
На следующем рисунке показана многоуровневая структура приложений, поддерживаемая Alibaba (см. «Руководство по разработке Java для Alibaba»):
открытый уровень интерфейса
Он может напрямую инкапсулировать метод Service и предоставлять его как интерфейс RPC, инкапсулировать его в http-интерфейс через Интернет, выполнять контроль безопасности шлюза, управление потоком и т. д.
слой отображения терминала
Шаблоны на каждой стороне отображают и выполняют отображаемые слои. В настоящее время это в основном рендеринг скорости, рендеринг JS, рендеринг JSP, мобильный дисплей и т. д.
веб-уровень
Это в основном для переадресации управления доступом, проверки различных основных параметров или просто обработки немультиплексированных услуг.
Сервисный уровень
Относительно специфичный сервисный уровень бизнес-логики.
Слой менеджера
Общий уровень бизнес-обработки имеет следующие характеристики: 1) уровень, инкапсулирующий стороннюю платформу, предварительно обрабатывающий возвращаемые результаты и преобразовывающий информацию об исключениях; 2) использование общих возможностей уровня обслуживания, таких как решения для кэширования, промежуточное ПО. общая обработка; 3) взаимодействует с уровнем DAO и повторно использует комбинацию нескольких DAO.
Слой ДАО
Уровень доступа к данным взаимодействует с базовыми MySQL, Oracle, Hbase и т. д.
Внешние интерфейсы или сторонние платформы
Включая открытые RPC-интерфейсы других отделов, базовые платформы и HTTP-интерфейсы других компаний.
Обработка транзакции
Разобравшись со слоями, давайте рассмотрим вопрос, который больше всего беспокоит всех при написании веб-кода на Java, то есть когда речь идет об операциях с базой данных, какой уровень обработки транзакций следует контролировать?
В этом вопросе благожелательный видит благожелательность, а мудрый видит мудрость. Автор считает, что обработка транзакций должна быть размещена на уровне службы и уровне менеджера.
На уровне DAO не должно быть транзакций, это должен быть только более общий метод доступа к данным, такой как чистый CRUD. DAO должен обрабатывать только операции, связанные с ним самим, без какой-либо комбинации. Вопрос комбинирования оставлен на верхний уровень.
Уровень сервиса и уровень менеджера обычно объединяют несколько операций DAO CRUD.Например, при регистрации пользователя вам нужно вставить журнал в таблицу журналов, затем создать транзакцию на уровне сервиса и вызвать User.Insert Слой Dao в транзакции () и Log.Insert().
Обработка исключений
Обработка исключений — важная тема в Java. В статье «Эффективная Java» есть множество передовых методов обработки исключений, которые не будут здесь подробно описываться. исключения, перехватывать их или выбрасывать на верхний уровень.
Во-первых, исключения могут возникать на каждом уровне. Поскольку обязанности каждого слоя разные, методы обработки также могут быть разными.
Слой ДАО
На уровне DAO может быть много типов исключений, которые могут быть исключениями, связанными с SQL, или исключениями, связанными с подключением к базе данных.
Метод обработки этого слоя может быть проще, напрямую try-catch (Exception), а затем инкапсулировать его как DAOException и кинуть на верхний уровень. Обычно этому уровню не нужно печатать журнал, и он передается для печати на уровень службы или менеджера.
try{
CRUD
}catch(Exception e){
throw new DAOException(e);
}
Manager/Service
В первую очередь должно быть перехвачено исключение, генерируемое слоем DAO, и журнал распечатан на сцене.
Но стоит отметить, что если это метод, требующий управления транзакциями, обратите внимание на создание нового исключения, такого как TransactionRolledbackException, после перехвата исключения, иначе транзакцию нельзя будет откатить.
Исключения, возникающие в этих двух слоях, могут быть решены в зависимости от ситуации, следует ли продолжать бросать вверх или разбираться с ними самостоятельно. Если это исключение, которое можно обработать само по себе, зафиксируйте его, зарегистрируйте, а затем верните на верхний уровень с помощью ErrorCode и других методов. Если это исключение, которое вы не можете обработать или не знаете, как обработать, отправьте его непосредственно на верхний уровень для его обработки.
Web
Во-первых, ясно, что веб-уровень не должен генерировать исключения, потому что когда этот уровень генерирует исключение, это может привести к тому, что пользователи перейдут на недружественные страницы ошибок или даже увидят сообщения об ошибках.
Если вы понимаете, что это исключение приведет к тому, что страница не будет отображаться должным образом, вы должны сразу перейти на удобную страницу с понятным сообщением об ошибке.
открытый уровень интерфейса
Этот уровень, как и веб-уровень, не может создавать исключения. Обычно он возвращается внешнему вызывающему объекту через ErrorCode и ErrorMessage.
На этом уровне вы должны самостоятельно обрабатывать все исключения, определять ErrorCode и записывать журналы, чтобы облегчить устранение неполадок в будущем.
Суммировать
В этой статье в основном представлена схема многоуровневого кода в веб-проектах Java.После многоуровневого разделения каждый слой может быть более сфокусирован и разделен. И кратко представил логику обработки транзакций и обработки исключений после расслоения.