A
Всем привет
Size: a a a
2020 December 08
Э
Askold
Почему нужно(или не нужно)) имплементировать интерфейсы репозитории в классах сервисах интерфейсах, то есть сначала репозиторий с Jpa -> сервисы интерфейс набором методов, и класс сервис который имплементирует/реализует интерфейс с набором методов(который заимплементился от интерйса репозитория) Получается интерфейс ради интерфейса?) Почему бы классу сервису напрямую не имплементировать интерфейсы репозитории...?))
почему бы дому не имплементировать интерфейс писуара?
k
Askold
Почему нужно(или не нужно)) имплементировать интерфейсы репозитории в классах сервисах интерфейсах, то есть сначала репозиторий с Jpa -> сервисы интерфейс набором методов, и класс сервис который имплементирует/реализует интерфейс с набором методов(который заимплементился от интерйса репозитория) Получается интерфейс ради интерфейса?) Почему бы классу сервису напрямую не имплементировать интерфейсы репозитории...?))
Потому что у репозитория могут быть методы, которых не должно быть в сервисе
К примеру, в UserRepository может быть метод getByUsername, который нужен в AuthService, но не нужен в UserService
Ну и все-таки интерфейс репозитория - это интерфейс работы с сущностями из БД, тогда как интерфейс сервиса - это контракт бизнес логики
К примеру, в UserRepository может быть метод getByUsername, который нужен в AuthService, но не нужен в UserService
Ну и все-таки интерфейс репозитория - это интерфейс работы с сущностями из БД, тогда как интерфейс сервиса - это контракт бизнес логики
AE
Пока что сервисы, планируется и по.
Разделение , что бы убрать "шумных соседей".
Возможно зря по разделению (топик/раздел) парюсь?
Разделение , что бы убрать "шумных соседей".
Возможно зря по разделению (топик/раздел) парюсь?
Ок, параллельно со спором "мало топиков и много типов сообщений в топике" vs "топик на так сообщения" есть ещё "определенные сообщения в определенные топики vs топик на сервис", рассмотрим его
В обоих случаях есть плюсы и минусы, для первого плюс - за сообщением закреплены топики (обычно один), ты просто в него шлёшь и все, но возникает проблема (минус) - всем ли потребителям нужны все сообщения этого типа?
Для второго типа картина другая, если сообщение попало в топик, значит оно нужно клиенту, это плюс - ведь не надо решать сервису оно нужно или нет, просто станет и обрабатывает, но есть и минус - отправитель должен решить кому нужно это уведомление. Для решения этой проблемы есть паттерн ESB(enterprise service bus), это координатор, ты ему все сообщения сваливаешь в топик и он уже решает кому в какой топик их послать. Минус тут в том, что логику кому нужно сообщение все равно писать, только в ESB, обычно для этого делают систему адресации, дополняют сообщения метаинформацией и т.д.
Как по мне все таки первый вариант проще и лучше, пусть сообщения определенных типов летят в определенные топики, пусть сервисы читают интересующие их топики, к тому же случай, когда сервису нужны не все сообщения типа бывает очень редко и сервис способен самостоятельно решить все. Городить адресацию с ESB не легко и требуется это в очень ограниченном количестве случаев, например при взаимодействии уже между системами, а не сервисами внутри системы
В обоих случаях есть плюсы и минусы, для первого плюс - за сообщением закреплены топики (обычно один), ты просто в него шлёшь и все, но возникает проблема (минус) - всем ли потребителям нужны все сообщения этого типа?
Для второго типа картина другая, если сообщение попало в топик, значит оно нужно клиенту, это плюс - ведь не надо решать сервису оно нужно или нет, просто станет и обрабатывает, но есть и минус - отправитель должен решить кому нужно это уведомление. Для решения этой проблемы есть паттерн ESB(enterprise service bus), это координатор, ты ему все сообщения сваливаешь в топик и он уже решает кому в какой топик их послать. Минус тут в том, что логику кому нужно сообщение все равно писать, только в ESB, обычно для этого делают систему адресации, дополняют сообщения метаинформацией и т.д.
Как по мне все таки первый вариант проще и лучше, пусть сообщения определенных типов летят в определенные топики, пусть сервисы читают интересующие их топики, к тому же случай, когда сервису нужны не все сообщения типа бывает очень редко и сервис способен самостоятельно решить все. Городить адресацию с ESB не легко и требуется это в очень ограниченном количестве случаев, например при взаимодействии уже между системами, а не сервисами внутри системы
AE
поддержим лайками feature request?
https://github.com/rzwitserloot/lombok/issues/2669
https://github.com/rzwitserloot/lombok/issues/2669
A
почему бы дому не имплементировать интерфейс писуара?
Не логичная аналогия и не к месту
A
Потому что у репозитория могут быть методы, которых не должно быть в сервисе
К примеру, в UserRepository может быть метод getByUsername, который нужен в AuthService, но не нужен в UserService
Ну и все-таки интерфейс репозитория - это интерфейс работы с сущностями из БД, тогда как интерфейс сервиса - это контракт бизнес логики
К примеру, в UserRepository может быть метод getByUsername, который нужен в AuthService, но не нужен в UserService
Ну и все-таки интерфейс репозитория - это интерфейс работы с сущностями из БД, тогда как интерфейс сервиса - это контракт бизнес логики
- это контракт бизнес логики ключевой аргумент) далеко не все придерживаются этого мнения, многие считают что это лишнее, мое субъективное мнение таково что интерфейс и его реализация это как поговорка: "семь раз отмерь, один раз отрежь", интерфейс это чертёж, а его реализация это дом, и если чертеж дерьмовый то и дом скорее всего так себе например,
и при грамотном планировании, можно легко заменить одну реализацию интерфейса на другую, и не нужно будет рефачить кучу старого кода, прогнал тесты, а тесты написаны по интерфейсу.
и при грамотном планировании, можно легко заменить одну реализацию интерфейса на другую, и не нужно будет рефачить кучу старого кода, прогнал тесты, а тесты написаны по интерфейсу.
A
Потому что у репозитория могут быть методы, которых не должно быть в сервисе
К примеру, в UserRepository может быть метод getByUsername, который нужен в AuthService, но не нужен в UserService
Ну и все-таки интерфейс репозитория - это интерфейс работы с сущностями из БД, тогда как интерфейс сервиса - это контракт бизнес логики
К примеру, в UserRepository может быть метод getByUsername, который нужен в AuthService, но не нужен в UserService
Ну и все-таки интерфейс репозитория - это интерфейс работы с сущностями из БД, тогда как интерфейс сервиса - это контракт бизнес логики
Не обязательно, чаще всего то что в репозитории UserRepository тоже самое и в классе сервисе UserService например
РН
Askold
Почему нужно(или не нужно)) имплементировать интерфейсы репозитории в классах сервисах интерфейсах, то есть сначала репозиторий с Jpa -> сервисы интерфейс набором методов, и класс сервис который имплементирует/реализует интерфейс с набором методов(который заимплементился от интерйса репозитория) Получается интерфейс ради интерфейса?) Почему бы классу сервису напрямую не имплементировать интерфейсы репозитории...?))
потому что сервис и репозиторий это разные штуки и они выполняют разные функции, а значит могут (и скорее всего будут) иметь разные наборы методов
хотя бывает что это выглядит не так очевидно, иногда например приложение может быть построено так что единственная работа сервиса это вызов репозитория и возврат результата, тогда стоит задуматься а нужен ли тебе слой сервиса в этом месте
хотя бывает что это выглядит не так очевидно, иногда например приложение может быть построено так что единственная работа сервиса это вызов репозитория и возврат результата, тогда стоит задуматься а нужен ли тебе слой сервиса в этом месте
A
Роман Нагаев
потому что сервис и репозиторий это разные штуки и они выполняют разные функции, а значит могут (и скорее всего будут) иметь разные наборы методов
хотя бывает что это выглядит не так очевидно, иногда например приложение может быть построено так что единственная работа сервиса это вызов репозитория и возврат результата, тогда стоит задуматься а нужен ли тебе слой сервиса в этом месте
хотя бывает что это выглядит не так очевидно, иногда например приложение может быть построено так что единственная работа сервиса это вызов репозитория и возврат результата, тогда стоит задуматься а нужен ли тебе слой сервиса в этом месте
Если мало бизнес логики?) Микросервис имеете ввиду?
РН
Askold
Если мало бизнес логики?) Микросервис имеете ввиду?
я не говорил что бизнес логики мало, а скорее то что её может не быть на уровне сервисов если она например реализуется базой
и не имел в виду микросервис
я скорее имел в виду случаи когда репозиторий вызывает запрос возвращающий уже готовые сагрегированные данные и бывает что такие данные прогоняют через слой сервиса просто потому что надо и в таком случае сервис будет иметь тот же контракт что и репозиторий и не будет делать никакой полезной работы
и не имел в виду микросервис
я скорее имел в виду случаи когда репозиторий вызывает запрос возвращающий уже готовые сагрегированные данные и бывает что такие данные прогоняют через слой сервиса просто потому что надо и в таком случае сервис будет иметь тот же контракт что и репозиторий и не будет делать никакой полезной работы
A
Роман Нагаев
я не говорил что бизнес логики мало, а скорее то что её может не быть на уровне сервисов если она например реализуется базой
и не имел в виду микросервис
я скорее имел в виду случаи когда репозиторий вызывает запрос возвращающий уже готовые сагрегированные данные и бывает что такие данные прогоняют через слой сервиса просто потому что надо и в таком случае сервис будет иметь тот же контракт что и репозиторий и не будет делать никакой полезной работы
и не имел в виду микросервис
я скорее имел в виду случаи когда репозиторий вызывает запрос возвращающий уже готовые сагрегированные данные и бывает что такие данные прогоняют через слой сервиса просто потому что надо и в таком случае сервис будет иметь тот же контракт что и репозиторий и не будет делать никакой полезной работы
Результаты процедур, курсоры, без участия моделек
YG
Askold
- это контракт бизнес логики ключевой аргумент) далеко не все придерживаются этого мнения, многие считают что это лишнее, мое субъективное мнение таково что интерфейс и его реализация это как поговорка: "семь раз отмерь, один раз отрежь", интерфейс это чертёж, а его реализация это дом, и если чертеж дерьмовый то и дом скорее всего так себе например,
и при грамотном планировании, можно легко заменить одну реализацию интерфейса на другую, и не нужно будет рефачить кучу старого кода, прогнал тесты, а тесты написаны по интерфейсу.
и при грамотном планировании, можно легко заменить одну реализацию интерфейса на другую, и не нужно будет рефачить кучу старого кода, прогнал тесты, а тесты написаны по интерфейсу.
Ну вы говорите джава интерфейс. Сигнатура функции тоже хороший интерфейс
Э
Askold
Не логичная аналогия и не к месту
дом - сервис. Писуар - репозиторий. Писуар в доме. Репозиторий заинжекчен в сервис. Что не так?
Я чисто на это отреагировал:
> Почему бы классу сервису напрямую не имплементировать интерфейсы репозитории...?))
Я чисто на это отреагировал:
> Почему бы классу сервису напрямую не имплементировать интерфейсы репозитории...?))
O
дом - сервис. Писуар - репозиторий. Писуар в доме. Репозиторий заинжекчен в сервис. Что не так?
Я чисто на это отреагировал:
> Почему бы классу сервису напрямую не имплементировать интерфейсы репозитории...?))
Я чисто на это отреагировал:
> Почему бы классу сервису напрямую не имплементировать интерфейсы репозитории...?))
То есть, когда мы из репозитория тянем данные, то это мы из писсура что-то достаём? Ну и аналогии у вас.
Э
То есть, когда мы из репозитория тянем данные, то это мы из писсура что-то достаём? Ну и аналогии у вас.
суть не в этом, госпаде.
Я об отношении A
На место A ставим сервис, на B - репо
Бля, ты рофлишь?
Я об отношении A
has a BНа место A ставим сервис, на B - репо
Бля, ты рофлишь?
A
дом - сервис. Писуар - репозиторий. Писуар в доме. Репозиторий заинжекчен в сервис. Что не так?
Я чисто на это отреагировал:
> Почему бы классу сервису напрямую не имплементировать интерфейсы репозитории...?))
Я чисто на это отреагировал:
> Почему бы классу сервису напрямую не имплементировать интерфейсы репозитории...?))
Все не так, ну во первых у каждого свой вкус на юмор, во вторых не инжектится, а имплементится, дом и писуар, то есть уборная, это в корне не то
O
суть не в этом, госпаде.
Я об отношении A
На место A ставим сервис, на B - репо
Бля, ты рофлишь?
Я об отношении A
has a BНа место A ставим сервис, на B - репо
Бля, ты рофлишь?
то есть,репозиторий часть сервиса? ну это спорный вопрос?
A
суть не в этом, госпаде.
Я об отношении A
На место A ставим сервис, на B - репо
Бля, ты рофлишь?
Я об отношении A
has a BНа место A ставим сервис, на B - репо
Бля, ты рофлишь?
Вы не поняли суть вопроса, или я как минимум не понимаю вас
Э
Askold
Все не так, ну во первых у каждого свой вкус на юмор, во вторых не инжектится, а имплементится, дом и писуар, то есть уборная, это в корне не то
репо имплементит сервис?