Держите свой код хорошо организованным. Как я структурирую свой веб-проект

Статья, первоначально размещенная на моем личном веб-сайте по адресу Как организовать свой веб-проект

Легко увлечься и просто написать код. Код может даже работать так, как задумано, но поверьте мне, что через 6 месяцев вы больше не будете знать, что он делает и где найти конкретную функциональность. Если только у вас нет чистой и четкой структуры. Я не обязательно говорю о самих классах, но о том, как правильно организовать функциональные возможности в пакетах, чтобы, когда потребуется внести изменения через 6 или 12 месяцев, вы точно знали, где искать.

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

Основные части веб-приложения

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

Контроллер

Это основная точка входа в приложение, и обычно она сопоставляется с одной или несколькими конечными точками, доступными через веб-браузер. Контроллер получает HTTP-запрос и возвращает HTTP-ответ обратно клиенту. Не имеет значения, используете ли вы Spring, Play или любой другой фреймворк, контроллер должен обрабатывать запрос и только запрос.

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

Основными обязанностями контролера должны быть только:

Получение запроса
Подтверждаю это
Сопоставление запроса с внутренним объектом данных (здесь он должен делегировать запрос картографу)
Вызов службы
Сопоставление результирующего объекта с HTTP-ответом
Возврат ответа

Услуга

Служба – это компонент, который отвечает за выполнение бизнес-логики. Любые вычисления, бизнес-проверки и бизнес-операции должны обрабатываться здесь. Служба может вызывать и делегировать часть функциональности другим службам, за исключением сохранения данных, что должно быть сделано в DAO.

Здесь может быть легко иметь классы Бога, которые делают много (несвязанных) вещей. Это нормально – иметь много сервисов, которые взаимодействуют друг с другом. Постарайтесь разделить свои классы на основе того, что они делают, и не переоценивать ответственность службы. Управляете ли вы пользователями? Есть служба “Пользователи”. Позволяет ли ваш сайт размещать статьи, есть ли сервис “Статьи”? А как насчет комментариев? Как вы уже догадались, это сервис “Комментариев”. Да, вам нужен зарегистрированный пользователь для публикации статей, чтобы службы ‘Article’ и ‘Users’ могли взаимодействовать друг с другом, но не выполняйте метод ‘submitNewArticle(User user, String Articletext)’ внутри службы Users только потому, что вы используете пользовательский объект.

Данные

Это часть приложения, которая обрабатывает сохраненные и переданные данные. Именно здесь мы должны хранить объекты домена (DO), Объекты передачи (DTO), Уровень доступа (DAO) и, по крайней мере, в моем случае, необходимые фильтры. Имейте в виду, что они должны быть правильно упакованы в пакеты. Не храните классы с разными обязанностями в одних и тех же пакетах.

Другие

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