Spring MVC (Hibernate + Maven) - Несколько контроллеров и сеансов (вход/выход)

Question

Я работаю над проектом среднего размера с использованием Spring MVC, Hibernate и Maven.

Мое приложение имеет страницу входа, которая аутентифицирует пользователей, а затем направляется на главную страницу с меню. Из меню пользователь может перейти к нескольким опциям меню. Приложение разделено на несколько модулей - сотрудников, начисление заработной платы, отсутствие управления и т. Д.

Довольно новая на этой платформе и имеет несколько вопросов.

1. Контроллеры: Должен ли я использовать один контроллер для всего приложения или использовать несколько контроллеров?

2. Если я должен использовать несколько - должен ли он быть одним контроллером для модуля входа и по одному для каждого модуля, такого как сотрудник, платежная ведомость и т. Д.? Как я могу заставить их говорить друг с другом и проходить контроль?

   Какое должно быть возвращаемое значение метода, помеченного с помощью @RequestMapping? Если я просто передаю возвращаемое значение как «return» Employee », и у меня есть Employee.jsp в моих представлениях, но связанные с Employee вещи находятся в EmployeeController, как я могу убедиться, что мой код еще не застрял в предыдущем контроллере (например LoginController)?

   Должен ли я создать главный контроллер для управления всеми этими контроллерами?

3. Чтобы сохранить учетные данные пользователя на всех страницах, мне нужно будет использовать объект сеанса в модуле входа? Или будет ли Spring MVC обрабатывать по умолчанию?

Я нашел несколько релевантных страниц. Они хороши, но они объясняют очень простые сценарии и не были полезны для моей реальной проблемы.

Получу вашу помощь по вышеуказанным вопросам. Спасибо!

Answer 1

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

• Single Ответственность главного
• разделения проблем

Это, как правило, приемлемо, чтобы создать контроллер, который принимает несколько URI конечных точек, которые манипулируют конкретная модель для операций CRUD, поскольку эти конечные точки часто принимают идентичные или почти идентичные типы ввода. Но для создания контроллера для разных моделей или всего приложения для меня нарушаются две точки выше; однако, ваше право на ваше мнение :).

Чтобы понять связь с контроллером, вам нужно понять, как работает HTTP в общем смысле. Веб-приложение - не более чем причудливый способ разработки системы запроса-ответа. Вы указываете браузеру перейти к определенному URL-адресу и отправляет этот запрос на сервер. Сервер интерпретирует ваш запрос, может манипулировать локальным серверным состоянием, возможно, запрашивает хранилище данных, если это применимо, и, наконец, отвечает на ответ. Этот ответ может носить статический или динамический характер. Динамический ответ может быть перенаправлен на технологию просмотра, чтобы отобразить конечный контент, который вы получаете. Эти технологии просмотра также могут быть серверными, такими как JSP/JSF или клиентскими, такими как Angular.

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

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

Так что, пример

@Controller 
public class EmployeeController { 
    @RequestMapping("/employee/view") 
    public String viewEmployee(@RequestParam("id") Integer id, Model model) { 
    // lookup the employee by the passed "?id=123" 123 value 
    final Employee employee = employeeService.getEmployee(id); 

    // set the employee in the model so I can render it in JSP 
    model.addAttribute("employee", employee); 

    // return the name of what view to display 
    return "view"; 
    } 
} 

Этот код, показанный здесь не будет застрял в «предварительного» контроллера, поскольку пользователю необходимо отправить форму или нажмите на ссылку или кнопку, чтобы отправить запрос к серверу, как /employee/view?id=123, чтобы этот контроллер выполнил свою работу.

И, наконец, да, объект HttpSession необходим для отслеживания состояния по нескольким запросам. HttpRequest - это недолговечный объект, из которого от десятков до сотен человек выполняют один пользователь на протяжении всего своего времени HttpSession.

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