Сервлеты, слушатели, jdbc

Такое дело, необходимо выполнить учебный проект - веб приложение, студенты, пары, преподы и т.д.
Использовать сессии, слушатели, шаблон MVC(не фреймворк) и фреймворки использовать нельзя.
Так вот, я уже 3ий день не могу разобраться, какая должна быть структура приложения... сущности и дао написал, а дальше понятия не имею. Конкретно в чем наибольшая проблема - не понимаю, как "по красивому" и со слушателями организовать ту же регистрацию пользователей в системе. Есть пример, который мне во многом понятен, но проблема та же - вот сервлет регистрации https://github.com/infostroytr... rvlet.java и я никак не могу понять, как из него в итоге мы приходим к https://github.com/infostroytr... rvice.java (ну а там дальше уже вижу, где вызывается дао).
Подскажите плс или по моему примеру или скиньте какой-то наиболее понятный, чтобы я понял хоть структуру папок и как все организовывать.

0

Сам не большой дока в сервлетах, но мне кажется здесь довольно очевидным как происходит обращение к PostgreUserService. При создании сервлета сначала запускается метод service(), после выполняется метод init(), в котором, собственно и инициализируется тот же userService, получая из контекста объект, который потом преобразовывается в тот самый PostgreUserService. Собственно, поэтому поле сервлета userService не null, когда происходит обращение к методу userService.register(user) в doPost.
Или ты имеешь в виду что-нибудь другое?

0

Сообщение от El Ahrairah Сам не большой дока в сервлетах, но мне кажется здесь довольно очевидным как происходит обращение к PostgreUserService. При создании сервлета сначала запускается метод service(), после выполняется метод init(), в котором, собственно и инициализируется тот же userService, получая из контекста объект, который потом преобразовывается в тот самый PostgreUserService. Собственно, поэтому поле сервлета userService не null, когда происходит обращение к методу userService.register(user) в doPost. Или ты имеешь в виду что-нибудь другое?

Ну вот я сейчас только начал читать про dependency injection, я так понимаю все через нее в этом проекте работает. Но тут "который потом преобразовывается в тот самый PostgreUserService." как именно это в коде происходит, пока не знаю.

0

Не совсем так. Здесь, по сути, обыкновенные операции с объектами, никаких больших наворотов типа DI нет. В классе AppContextListener явно создается(а не контейнером, что и отличает Dependency Injection) объект PostgreUserService, после он все так же явно кладется в объект контекста и уже потом, при инициализации сервлета регистрации и его полей, этот объект достается и присваивается полю сервлета.

Грубо говоря, если бы это был DI, то над полем userService висела одна из аннотаций @Inject, @EJB, @Autowired(в случае Spring Framework), а сам класс PostgreUserService был такжe помечен аннотацией как JavaBean(или был описан в xml-файле) и его созданием и всем жизненным циклом занимался бы контейнер.

Советую почитать официальную документацию по J2EE, которая крайне детальна и разбирает подобного рода тонкости. Как по Servlet API, так и по DI в J2EE.

Добавлено через 9 минут
Относительно того, как именно происходит преобразование. Здесь все довольно элементарно, так как здесь используется попросту возможности ООП. Класс PostgreUserService имплементирует интерфейс UserService(а значит вынужден реализовывать методы, описанные в UserService), после создав объект этого класса и присвоив его переменной UserService userService(а мы это может сделать в силу все того же ООП) мы пользуемся методами, описанных в интерфейсе, но реализованных в классе, имплементирующего этот интерфейс.

А это все значит, то тебе непременно стоит повторить основы языка, потому как на принципах ООП базируется разработка приложений на Java и уж тем более на J2EE.

1

Сообщение от El Ahrairah Не совсем так. Здесь, по сути, обыкновенные операции с объектами, никаких больших наворотов типа DI нет. В классе AppContextListener явно создается(а не контейнером, что и отличает Dependency Injection) объект PostgreUserService, после он все так же явно кладется в объект контекста и уже потом, при инициализации сервлета регистрации и его полей, этот объект достается и присваивается полю сервлета. Грубо говоря, если бы это был DI, то над полем userService висела одна из аннотаций @Inject, @EJB, @Autowired(в случае Spring Framework), а сам класс PostgreUserService был такжe помечен аннотацией как JavaBean(или был описан в xml-файле) и его созданием и всем жизненным циклом занимался бы контейнер. Советую почитать официальную документацию по J2EE, которая крайне детальна и разбирает подобного рода тонкости. Как по Servlet API, так и по DI в J2EE.

Да, теперь понял, спасибо.

0