k
interface repo1 extends JpaRepository<...>, MyRepo {...}
interface MyRepo { }
class MyRepoImpl {}
interface MyRepo { }
class MyRepoImpl {}
Size: a a a
2020 June 14
R
Если я правильно понял фразу, то так и делают
А не знаешь, чем критерии кроме метамодели отличается jpa от hibernate ?
R
Мне сказали добавить критеорию, а тема для меня новая и поэтому нету такого экспириенса, чтобы предсказать, что лучше для проекта.
AE
Есть такая задача. Необходимо создать 10 объектов бина
B (строго 10, не больше и не меньше) и хранить их в коллекции бина A. Понятно что можно сделать скоуп prototype у бина `B1, но проблема в том что это работает только когда мы дергаем контекст. В спринге есть возможность заинжектить коллекцию объектов определенного типа, но там будет только по одному объекту каждого класса. Как решить данную проблему? Если контекст инжектить плохая идея.Эти 10 инствнсов должны различается конфигурацией или повидением?
AE
Ребят, если я юзаю дто а не дао, то куда мне лучше разместить логику Криттерии апи?
Дто и дао о разном совсем
AE
А не знаешь, чем критерии кроме метамодели отличается jpa от hibernate ?
Критерии есть только в jpa, соответственно в хибере они те же самые
AE
Мне сказали добавить критеорию, а тема для меня новая и поэтому нету такого экспириенса, чтобы предсказать, что лучше для проекта.
Для чего добавить?
AL
Эти 10 инствнсов должны различается конфигурацией или повидением?
Нет
AE
А зачем тогда их 10 штук?
AL
А зачем тогда их 10 штук?
потоки .для обработки информации
AE
потоки .для обработки информации
Почему не использовать ThreadPool?
AE
потоки .для обработки информации
Если в тредах для обработки данных нужны бины, то делай просто захват в сервисе, делов то
AL
Почему не использовать ThreadPool?
Потому что можно и нужно использовать. Но там мне нужен инжект бинов
AE
Потому что можно и нужно использовать. Но там мне нужен инжект бинов
Так сделай в сервисе запуск 10 потоков на пуле
AL
Так сделай в сервисе запуск 10 потоков на пуле
Так и делается
AL
Но я обращаюсь к контексту. Буду переделывать без обращения к нему
Д
#toAdmins
AT
#toAdmins
EI
Подскажите, пожалуйста, есть следующие классы:
- OrderService - отвечает за логику работы с заказами (создание, смена статуса) с различными валидациями корректности данных и бизнес логики. Он работает с OrderRepository.
- CourierNotificationService - отвечает за доставку push уведомлений курьерам
- UserNotificationService - доставка push уведомлений пользователям
Сейчас дёргается OrderController и создаётся заказ через OrderService.
А теперь хочется доставлять уведомления, что заказ создан.
Очевидно: внедрить UserNotificationService и CourierNotificationService в OrderService и пусть он их вызывает.
Правильно ли так делать? Кажется, что OrderService не должен заниматься этим, так как его задача просто работа с заказами с кучкой валидаций.
Может еще один класс сверху, типа OrderManager, который будет дергать уже OrderService, UserNotificationService и CourierNotificationService?
В общем, как в таких случаях правильно строить логику?
- OrderService - отвечает за логику работы с заказами (создание, смена статуса) с различными валидациями корректности данных и бизнес логики. Он работает с OrderRepository.
- CourierNotificationService - отвечает за доставку push уведомлений курьерам
- UserNotificationService - доставка push уведомлений пользователям
Сейчас дёргается OrderController и создаётся заказ через OrderService.
А теперь хочется доставлять уведомления, что заказ создан.
Очевидно: внедрить UserNotificationService и CourierNotificationService в OrderService и пусть он их вызывает.
Правильно ли так делать? Кажется, что OrderService не должен заниматься этим, так как его задача просто работа с заказами с кучкой валидаций.
Может еще один класс сверху, типа OrderManager, который будет дергать уже OrderService, UserNotificationService и CourierNotificationService?
В общем, как в таких случаях правильно строить логику?
AE
Подскажите, пожалуйста, есть следующие классы:
- OrderService - отвечает за логику работы с заказами (создание, смена статуса) с различными валидациями корректности данных и бизнес логики. Он работает с OrderRepository.
- CourierNotificationService - отвечает за доставку push уведомлений курьерам
- UserNotificationService - доставка push уведомлений пользователям
Сейчас дёргается OrderController и создаётся заказ через OrderService.
А теперь хочется доставлять уведомления, что заказ создан.
Очевидно: внедрить UserNotificationService и CourierNotificationService в OrderService и пусть он их вызывает.
Правильно ли так делать? Кажется, что OrderService не должен заниматься этим, так как его задача просто работа с заказами с кучкой валидаций.
Может еще один класс сверху, типа OrderManager, который будет дергать уже OrderService, UserNotificationService и CourierNotificationService?
В общем, как в таких случаях правильно строить логику?
- OrderService - отвечает за логику работы с заказами (создание, смена статуса) с различными валидациями корректности данных и бизнес логики. Он работает с OrderRepository.
- CourierNotificationService - отвечает за доставку push уведомлений курьерам
- UserNotificationService - доставка push уведомлений пользователям
Сейчас дёргается OrderController и создаётся заказ через OrderService.
А теперь хочется доставлять уведомления, что заказ создан.
Очевидно: внедрить UserNotificationService и CourierNotificationService в OrderService и пусть он их вызывает.
Правильно ли так делать? Кажется, что OrderService не должен заниматься этим, так как его задача просто работа с заказами с кучкой валидаций.
Может еще один класс сверху, типа OrderManager, который будет дергать уже OrderService, UserNotificationService и CourierNotificationService?
В общем, как в таких случаях правильно строить логику?
Тут можно использовать систему уведомлений спринга, почитайте про ApplicationEvent