LINUX.ORG.RU

1.Когда нужно использовать один или другой?

Технически, они ничем не отличаются. С точки зрения структуры, service дополнительно маркает бин, что это не просто какой-то компонент, а часть сервисного слоя.

См. документацию

Indicates that an annotated class is a "Service", originally defined by Domain-Driven Design (Evans, 2003) as "an operation offered as an interface that stands alone in the model, with no encapsulated state."

hippi90 ★★★★★
()
Ответ на: комментарий от Lusine

Попроще, разницы нет, работают одинаково.

Возьми самый простой crud, у тебя будет три слоя в приложении - контроллер, в котором ты определяешь ресты, репозитории, которые умеют работать с БД и сервисы, которые знают как обработать запрос и в какой репозиторий сходить. Можно сервисы пометить @Component? Можно, работать будет так же. Но принято отмечать их как @Service, просто для удобства

hippi90 ★★★★★
()
  1. Технически разницы нет. Обычно все используют @Service.

  2. Неправда, гораздо быстрей.

vbr ★★★★★
()
Последнее исправление: vbr (всего исправлений: 1)
Ответ на: комментарий от Lusine
  1. Технически пофиг. А практически чтоб тебе было понятнее в своём коде у тебя есть выбор обзывать то что ты делаешь сервисом или компонентом.

  2. Нет, иногда, it depends. Тут смотри какая штука: идеально написанная программа на Java всегда будет медленнее идеально написанной программы на C++, которая в свою очередь проиграет сишке и растишке (но не так сильно, сишка при этом немного выиграет у растишки за счёт того что позволяет делать грязные и очень опасные вещи), а те проиграют идеальному ассемблерному коду (с оговоркой что пишет его первоклассный специалист). Но по факту, никто просто так не будет писать программу в 100 000 строк на C++, чтоб уделать программу в 1000 строк на Java. И не факт что даже если возьмутся, то из-за ошибок не сделают её хуже. Потому оптимизируют только то, что узко. В плане таких оптимизаций C++ выиграет у Java, но только если разработчик на C++ понимает что делает и не гнушается даже ассемблером. А уж про SIMD и говорить не приходится. Другое дело, что не в каждом алгоритме тебе помогут SIMD с ассемблером. Но там где помогут C++ порвёт Java как тузик грелку, пока у последней не доделают вальгалу (а зная как долго её делают, я поверю что ИИ будет всё писать к тому моменту, когда это случится вообще без участия человека). ИРЛ зная уровень «сеньоров» на отечественном рынке труда (почему он такой оставим на размышление тебе, когда будешь искать работу), то написать качественный и быстрый код (SIMD, ассемблерные вставки, серьёзная математическая оптимизация алгоритмов и их выбор под конкретную задачу, учитывая не только O(N), но и реальный объём данных на которых работает алгоритм конкретно в их программе, например, сортировка пузырьком будет быстрее ванильного квиксорта с куда лучшим O(N), если надо сортировать группы по 5 элементов), на C++ смогут полтора человека. Но бодаться с тяжёлой Java в прогретой виртуальной машине трудно - из-за того что она не просто компилируется, а переводится в байт код и исполняется в виртуальной машине, последняя на основе статистики может делать дополнительные оптимизации на лету, ускоряя хреново написанный код. И выходит что если код написан одинаково плохо на C++ и Java (а это именно так в больших программах, чем она больше, тем больше там говна), то Java запросто и победит его.

peregrine ★★★★★
()
Последнее исправление: peregrine (всего исправлений: 1)
Ответ на: комментарий от peregrine

А уж про SIMD и говорить не приходится. Другое дело, что не в каждом алгоритме тебе помогут SIMD с ассемблером

1brc challenge смотрит на это с ухмылкой

cobold ★★★★★
()
Ответ на: комментарий от cobold

Он с SIMD через Graal. Со всеми плюсами и минусами самого Graal (не всякий Java код будет работать в Graal, рефлексия и всё что с ней связано не смогут, если специальным, особо геморройным методом их не делать).

peregrine ★★★★★
()
Ответ на: комментарий от peregrine

пока у последней не доделают вальгалу

Уже заморжили, в следующем JDK будет первая итерация. Думаю к LTS доведут до минимально полезного состояния.

maxcom ★★★★★
()
  1. Пофиг.
  2. И лет 20 назад на кывте, и с год назад на лоре видел оценки, что среднестатистическая реальная программа на C++ быстрее жавы раз в 30. Это совпадает с моими ощущениями и как юзера (e.g. отзывчивость QtCreator vs IDEA – и то, и другое не дураками написано), и как программиста (суммарно наверное лет по 10 что в том, что в другом; и моя оценка не про безумно-заумный стек jee/spring). А любителей длинно рассуждать о нюансах и кейсах я скромненько спрошу, на чём написаны AAA-игры.
dimgel ★★★★★
()
Ответ на: комментарий от peregrine

идеально написанной программы на C++, которая в свою очередь проиграет сишке и растишке

Довольно спорный момент в сравнении C++ vs Rust. Откуда у последнего будет преимущество в производительности? Там

anonymous
()
Ответ на: комментарий от anonymous

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

peregrine ★★★★★
()
  • Markdown
Пустая строка (два раза Enter) начинает новый абзац. Знак '>' в начале абзаца выделяет абзац курсивом цитирования.
Внимание: прочитайте описание разметки Markdown.
Используйте Ctrl-Enter для размещения комментария