Народ, вопрос концептуального характера. Вот есть у нас в Java пакеты. Как вы организуете проект? Можно пологаться на какое-нибудь DDD, но тогда проект будет выглядеть как что-то слишком абстрактное. Очень часто вижу организацию именно в таком стиле: domain, controllers, инфраструктура итд. Но ведь это все отвязано от реальных кейсов, от структуры предметной области. Приходиться прыгать из пакета в пакет, ведь часто модель имеет отношение к конкретному сервису, а они лежат в разных пакетах. Кто-то группирует классы по семантической структуре проекта и я считаю это более верным решением, нежели придерживаться паттерномании и методологии разработки ПО (ибо тогда слишком силен на этом акцент). А как делаете вы?

Разбитие по кейсам не тру, когда у тебя кейсов овер 30 начинается

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

Хочеться и слои сохранить и не потерять смысл.

Смысл не архитектурный, а предметной области.

в домене и бизнес слое так можно сделать

а контроллеры размазывать это уже плохо

а контроллеры размазывать это уже плохо

Согласен по поводу контроллеров.

Почему? Хочется видеть все контроллеры в одном пакете?

если одна кодовая база для десктопа и веба например, то так всегда раньше делали

Народ, вопрос концептуального характера. Вот есть у нас в Java пакеты. Как вы организуете проект? Можно пологаться на какое-нибудь DDD, но тогда проект будет выглядеть как что-то слишком абстрактное. Очень часто вижу организацию именно в таком стиле: domain, controllers, инфраструктура итд. Но ведь это все отвязано от реальных кейсов, от структуры предметной области. Приходиться прыгать из пакета в пакет, ведь часто модель имеет отношение к конкретному сервису, а они лежат в разных пакетах. Кто-то группирует классы по семантической структуре проекта и я считаю это более верным решением, нежели придерживаться паттерномании и методологии разработки ПО (ибо тогда слишком силен на этом акцент). А как делаете вы?

Это творческий вопрос. Цель разбивания по пакетам это порядок, чтоб ты мог быстро найти нужный модуль. Можно разбивать по слоям, Controller view domain logic... А внутри слоев по предметной области. А то что обращаешься в другой пакет что в этом плохого?

Можно и наоборот по предметной обл а внутри по типу

вот я и думаю, как лучше.

Лучшее враг хорошего

Вот представте приходит новый человек в команду, а вы ему: - Вот наш проект, вот код, смотри, а там model, view, controller, services. И вроде бы все понятно, а вроде и нет) потому-что ни слова о предметной области.

/stat@combot

combot.org/chat/-1001043090457

Вот представте приходит новый человек в команду, а вы ему: - Вот наш проект, вот код, смотри, а там model, view, controller, services. И вроде бы все понятно, а вроде и нет) потому-что ни слова о предметной области.

Открой Вью и смотри

Предметную область

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

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

Но ты знаешь что искать

Да, но тут помогают не пакеты а правила именования классов.

Был на проеке раз, где классы одинаково именовали но в разных пакетах были

Вот где ад был.

Ну так что, я решил забить на курсорную пагинацию, но может её кто-то таки делала на спринге?

А спринг то тут при чем?

Ps не делал.

Если я правильно тебя понял то тут больше вопрос к бд. И получается прийдется следить за тем чтобы курсор не протух.

Лучше вообще без пагинаций делать.

Лучше вообще без пагинаций делать.

Отдавать все сразу?

Отдавать все сразу?

Процесс выстроить так, чтобы только нужные данные выводились

В большинстве случаев тебе не нужно 100500 записей.

Ну вот у тебя бложик

Как возвращать данные

Ну это ж тривиально.

Обычную офсетную пагинацию делаешь как все.

Так без пагинации же

Лучше вообще без пагинаций делать.

This

Ну тогда последние n записей выводи

А остальные можно сразу удалять

А остальные - в архиве.

Пользователь же их уже никогда не прочитает

Сам понимаешь что говоришь?)

Да :)

Дичь, да?)

Web.archive.org

Или как он там назывался.

В Spring Data есть же пагинация

Ну вот в выдаче поисковика - редко кто пользуется пагинацией

Чаще - уточняют запрос поисковый

Если я правильно тебя понял то тут больше вопрос к бд. И получается прийдется следить за тем чтобы курсор не протух.

Не, не к бд вопрос, я о чем-то вроде того что делает Фейсбук и твиттер

Бесконечный скрол?

Ага

Так там под капотом не факт что курсоры

Можно просто новый запрос делать от последней загруженой записи

И это лучше чем офсеты вероятно

да, но тоже не выход, , если есть сортировка

Разбивать проект и пакеты нужно по доменам

Разбивать проект и пакеты нужно по доменам

?

Внутри - функциональная разбивка

хочу так

но не хочу писать руками

Каждый домен имеет апи

https://www.sitepoint.com/paginating-real-time-data-cursor-based-pagination/

ERROR: S client not available

Желательно домен оформить как модуль

хочу магию спринга, вжух, включи spring.data.cursor-based-paignation=enable

и у тебя в hateos уже все нужные линки

не хочу разбираться хочу магию

Так есть же спрингдата

Там pagination уже завезен

ну limit offset не перформансно тип

Ага на лимит офсет

Я для маленьких сервисов - свою пагинацию делал, это ж классик один и доп метод в репозитории

если 200к записей уже чувствуется

Я для маленьких сервисов - свою пагинацию делал, это ж классик один и доп метод в репозитории

Ну вот, а я склоняюсь к тому, что бы чуваки у себя на клиентах мерджили

Клиент тебе будет слать запрос на следующие данные

да, но нужно что-то, что показывает какие у него сейчас уже есть

что бы дать именно N следующих

Можно вообще так: первый запрос на N записей, ты возвращаешь их плюс ключ по которому клиент будет дальше тягать записи

Типа как курсор

вот это я и хочу

но из коробки

Ебна)

Тыж программист

Тыж программист

нет я джун, опыта нету и вообще мне лень

я что зря спринг выбрал?

Тут джуны не сидят

Тут все архитекторы и скалабигдата инженеры

/stat@combot

combot.org/chat/-1001043090457

Тут все архитекторы и скалабигдата инженеры

а так, это нужно нагенерить ключ, потом его парсить, я пока даже не сильно представляю как, это же в нем уже будет зашито направление и сортировка, как минимум

Ну зависит от базы, например elastic search сам управляет курсором

Тут все архитекторы и скалабигдата инженеры

Ну не надо уж так обощать.