×

Нужен совет юному Java падавану

Всем привет!
Вот учу я джаву, учу.... и опять учу.

И вот сейчас понял что с возникновением очередного вопроса, я опять потратил несколько дней в поисках ответа, но так и не нашел его. Вместо ответов попадаются одни Spring MVC туториалы, в которых надо вывести на страничку хелловорлд и все.

Посему обращаюсь за помощью к более опытным дамам и господам.

Помогите, пожалуйста, найти ответы на некоторые вопросы:

1. Вот если мы говорим о Spring MVC, где можно почитать о том, как строится его модель, как передать ему страничку, которую надо вернуть? Т.е. немного теории, где не будет написано по частям: «вот тебе аннотация @DoTheBest — она делает зе бест», а подробнее описывалось бы как с этим всем взлететь.

2. Куда в Spring MVC подевался слой модельной логики, который без спринга отвечал за то чтобы принять запрос с вью, послать через дао в базу гонца и потом вернуть новую страничку с результатами? (классы этого слоя еще command или service назывались)?

3. Без спринга мы делали фабрику, которая вызывалась в сервлете, принимала запрос с вью и «выплевывала» нужный для обработки именно этого запроса комманд (сервис). Не могу понять как это организовано в Спринге МВС.

В общем и целом запутался я немного. Спринг дату вроде как осилил по верхам — она работает (ходит в базу, проходит тесты и т.д.) а тут уже даже копипаст чужого кода перестал помогать, т.к. не понимаю что делаю. Помогите, пожалуйста линками на где почитать именно в таком разрезе можно.

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

У Spring & SpringMVC отличные доки, там есть все что нужно для понимания, как работает фреймворк. Совсем новичку их читать бесполезно, а вот человеку, который по tutorial писал какие-то приложения и хочет более глубоко разобраться — must read.
docs.spring.io/...reference/htmlsingle/#mvc

Я тоже учу джаву. И до определенного момента мне тоже Spring представлялся магической коробкой и сам функционал его был темен и непонятен.

Поэтому я сначала разобрался с Reflection, jdk dynamic proxy, написал свой игрушечный (но полностью рабочий) DI-контейнер, а потом прочитал Spring reference documentation от и до. И после этого Spring стал понятен сам собой. Не выучен на память, а именно понятен.

Подозреваю, что если возникают вопросы по Spring MVC, тем более по тому, как он работает с остальной объектной структурой приложения, то проблема в непонимании скорее всего лежит где-то глубже, чем владение самим Spring MVC как инструментом.

Попытайся написать REST-подобный пет-прожект на голой джаве (только JSE, база и сервлеты), без использования фреймворков вообще. И прилепи к нему такой же пет-фронтенд на какомнибудь ангуляре или реакте. В процессе ты наочно увидишь все те проблемы, которые фреймворки призваны решать, а не просто освоишь волшебный инструмент, который делает @DoTheBest :)

Допускаю, что этот этап тобой уже был пройден, но тогда и вопросов быть вроде как не должно.

В том-то и дело, что он был пройден (написано несколько однотипных MVC приложений с вьюхами, фильтрами, сервлетом, бизнес логикой, ДАО и базой) и я до недавних пор считал, что таки разобрался и со структурой и со всем остальным. А сейчас понял, что главное, чего я не понимаю — это то, что в Спринге от меня уже скрыто за очередным уровнем абстракции, а чего я все-таки вижу и сам пользую. Соответственно, что куда передает, откуда там берется вью+модель с каким образом осуществить переход на следующую страницу. И, наверное главное, это то, что похоже, в голове отложилось одно (контроллер == сервлет) а тут вроде как контроллеров уже много и каждый из них уже отвечает за свой сабмит. В общем потихоньку роюсь, но понимания еще нету.

(контроллер == сервлет)
Это вовсе не так. Контроллер гораздо шире, чем сервлет. Сервлет более атомарен по своей сути. Я бы сказал, что сервлет — это один эндпойнт, в общем простом случае.
Контроллер може быть коллекцией эндпойнтов, с гораздо более широкими возможностями маппинга и работы с URL.
Например, нельзя замапить сервлет на URL вида /app/orders/{orderId}/items/{itemId} или /app/orders/*/items/*, а контроллер можно.
откуда там берется вью+модель
Это ты сам решаешь, спринг не пишет бизнес-логику, он предоставляет «внешнюю экосистему» для твоих классов. Тебе самому нужно создать модели, сервисы, решить, каким будет вью, и заинжектить все это в контроллер. Спринг МВЦ не скрывает это ни за какой абстракцией — это просто не его зона ответственности.

Кроме того, если аппликуха на AJAX и, допустим, еще и SPA, то генерация view заканчивается на маппинге бизнес-объектов (или их коллекций, например) в JSON и отсылке их клиенту. View в понимании пользователя на клиенте отрисовывает какой-нибудь React\Angular, ему не нужны ни страницы, ни куски хтмла, ему нужна чистая дата в JSON, которую он будет тянуть из твоего API.

переход на следующую страницу
Переход на следующую страницу осуществляется либо через ссылку, либо редиректом.

Я сам джун, но, может, помогу. Советую глянуть в сторону идеологии RESTfull.
Если в двух словах, то не очень кошерно, когда твой контроллер возвращает СТРАНИЦУ с данными. В идеале у тебя должны быть отдельные контроллеры, которые возвращают/принимают только чистые данные (JSON, XML etc). Логика получения и обработки данных должна находиться в отдельных классах — т.н. сервисах. И когда клиент(веб-станица, мобильный клиент) хочет получить данные, то он обращается к нужному методу контроллера через его эндпоинт (например site.com/orders), получает данные и самостоятельно их отображает в нужном ему виде.

Что в итоге должно быть:
— Сервисы с бизнес логикой
— Контроллеры, через которые клиент может получить данные, используя сервисы.
— Сам клиент (опционально). Если делаешь view слой в этом же проекте, то у него должен быть свой собственный контроллер, отвечающий ТОЛЬКО за вид. Никаких данных из базы или ещё откуда-то он возвращать не должен.

Надеюсь, что не запутал тебя ещё больше. =)

Если хочешь, стучись в скайп: taras_serba

Спасибо за советы. Это все я уже реализовывал на чистой джаве ЕЕ + JSP + DB на базе шаблона MVC. так что до Спринга вроде все было ок. Заблудился именно в нем :)

Забей на жаву и на спринг с кучей бессмысленных мозгодробильных абстракций и «магии». Лучше переходи на Go. Там все просто и понятно. Основы Go изучаются за пару дней. Нормальный код сможешь писать через неделю.

И сколько в Украине есть джуниорских вакансий на Go?

Пока вакансий на Go больше, чем программистов, знающих Go

На jobs.dou.ua одна, rabota.ua — две. И где эти вакансии?

Нормальный код сможешь писать через неделю.
Lol

Что, даже не за 21 день? ))

ну да. Go — не плюсы

да. Там же нет легко запомниающихся и понятных имен классов, как в spring:
— SimpleBeanFactoryAwareAspectInstanceFactory
— AbstractSingletonProxyFactoryBean

Любопытно, как часто и зачем вам приходилось использовать эти классы? А главное зачем вы их запоминали? :)

Вот хороший совет. Спасибо. Бросил полтора года жизни (изучение джавы) и побежал становиться программистом за неделю :)

Лучше поздно, чем никогда. Следующая цитата из этой статьи отлично описывает ваше положение:

the sad truth is that the more complicated and incomprehensible the code, i.e. the deeper the investment in creating it, the more we feel pressure to retain it (the “sunk cost fallacy”)

Ну да. Как в том анекдоте: разок попробовал — не получилось — больше не пробуешь. Так и до продавца в маке недолго доразвиваться.

Таки да, очень толковая книга, даже есть в переводе на русский.

Без обид, но я рекомендовал бы вначале вообще почитать про архитектуру MVC, т.к., судя по вопросам, с этим не все ок) Лучший вариант для начинающих — Head first servlets and jsp. Лично я знакомился со Spring MVC по сферическому коню в вакууме — Spring pet clinic, гуглится легко. Удачи в изучении. ;-) P.S. Если не терпится найти ответы на заданные вопросы — то рекомендую начать гуглить с запроса «Dispatcher servlet», никакой магии там на самом деле нет)

Да все это вроде как и так понятно. Это похоже как с многопоточностью у меня сейчас: теорию прослушал, изучил как устроены процессоры многоядерные, их регистры, кеши и т.д. Понятно что изучил и вроде как понял в теории все многопоточные слова, что куда и чего синхронизировать должно. А как сел писать код — тут же дедлок и намертво. Т.е. ищу способ посмотреть на то же самое, но с другой стороны / под другим углом.

Поводил тренинг. Посмотрите материалы
drive.google.com/...5ikxy1D0ttdkZlMUxxQzVKVU0
Там и презентации, и рекомендуемые книги, и ссылка на проект в гитхабе (с историей). Единственное что не вышло — это записать видео на всех занятиях. Только первые

Підписатись на коментарі