Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Java Новый топик    Ответить
 трипл-таер архитектура (но не совсем) контроллер->сервис->репозиторий  [new]
andreykaT
Member

Откуда:
Сообщений: 2427
пришлось мне возиться с одним проектом.. обычный такой вебсервис. апи база все дела.
так вот чел который его делал упорно избегал среднего слоя. и фигачил работу с репозиторием прям в контроллере. т.е. вызовы репозитория и какая то там логика была внутри контроллера.

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

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

в целом, мой консервативный взгляд говорит мне, что сервис-слой таки нужен. даже если в контроллере останется один единственный вызов.

собссно что думаете вы?
22 июн 19, 13:32    [21913342]     Ответить | Цитировать Сообщить модератору
 Re: трипл-таер архитектура (но не совсем) контроллер->сервис->репозиторий  [new]
mayton
Member

Откуда: loopback
Сообщений: 42860
Я думаю что вы, как архитектор вашей системы имеете полное право выкидывать звенья системы
если нет мотивации к их использованию. В конечном счете принцип KISS никто не отменял
и никакой Spring не может вас советовать как вам делать ваш проект.

Что у вас там? В сервисах? Логика которую надо тестировать? Или состояние?

Лет 10 назад я считал что всем веб-приложениям нужен объект Session. Сегодня я вижу такие
решения которые спокойно работают без сесии, скейлятся и не испытывают каких-то
проблем по этому поводу. И с аутентификацией у них все в порядке.

Вобщем курс на упрощение я поддерживаю.
22 июн 19, 13:55    [21913346]     Ответить | Цитировать Сообщить модератору
 Re: трипл-таер архитектура (но не совсем) контроллер->сервис->репозиторий  [new]
chpasha
Member

Откуда:
Сообщений: 8593
andreykaT
что тогда в контроллере делать?

формально функция контроллера обработка запросов/ответов плюс авторизация. даже если благодаря спрингу в самом контроллере кода практически нет (а в случае spring data rest и контроллера нет), так что идея о том что

andreykaT
у меня вознили проблемы с обкладыванием тестами. т.е. мне надо писать по-сути апи тест.

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

andreykaT
сервис-слой таки нужен. даже если в контроллере останется один единственный вызов

я такого же мнения придерживаюсь. если проект основательный. коли какая-то хрень типа сборщика логов так пофиг.
22 июн 19, 14:01    [21913351]     Ответить | Цитировать Сообщить модератору
 Re: трипл-таер архитектура (но не совсем) контроллер->сервис->репозиторий  [new]
andreykaT
Member

Откуда:
Сообщений: 2427
понятно. ну а всё же в той же экосистеме спринга что внутри то держать контроллера? ну окей может какой-нибудь диспетчер сервисов? если один эндпойнт отвечает за много чего.
22 июн 19, 15:50    [21913380]     Ответить | Цитировать Сообщить модератору
 Re: трипл-таер архитектура (но не совсем) контроллер->сервис->репозиторий  [new]
вадя
Member

Откуда: Екатеринбург
Сообщений: 16782
andreykaT,
ну в общих чертах и я пришел к такому мнению - надо все упрощать, а не следовать догмам....
22 июн 19, 17:23    [21913403]     Ответить | Цитировать Сообщить модератору
 Re: трипл-таер архитектура (но не совсем) контроллер->сервис->репозиторий  [new]
PetroNotC Sharp
Member

Откуда:
Сообщений: 2446
andreykaT,
Ну если у вас из БЛ один метод дайМнеХХХ(...
конечно сервис слой не нужен.
22 июн 19, 18:20    [21913414]     Ответить | Цитировать Сообщить модератору
 Re: трипл-таер архитектура (но не совсем) контроллер->сервис->репозиторий  [new]
andreykaT
Member

Откуда:
Сообщений: 2427
PetroNotC Sharp
andreykaT,
Ну если у вас из БЛ один метод дайМнеХХХ(...
конечно сервис слой не нужен.

да. в том и вопрос. вроде бы и не нужен. а может всё же нужен??

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

мне кажется, субъективно конечно же. это выглядит несколько неряшливо. но.. возвращаясь к изначальному вопросу. я так понимаю, это всё же практикуется и не говнокод.
23 июн 19, 10:34    [21913526]     Ответить | Цитировать Сообщить модератору
 Re: трипл-таер архитектура (но не совсем) контроллер->сервис->репозиторий  [new]
mayton
Member

Откуда: loopback
Сообщений: 42860
Мы щас стартуем аналитику для пендосов. Так у нас в стеке даже Спринга нету. Хотя веб-слой
существует. Пока хватает облачных Jetty+GraphQL.

Вобщем... нужно быть сфокусированным именно на задаче. А не дро..ить шаблоны.

Летает бизнес-логика в контроллере? Ну и нормас. А кто хочет сказать что ты должен
ее перенести в сервисы - пусть расскажет (на примерах) какую конкретно выгоду это
принесет.

Кроме логгирования конечно.
23 июн 19, 10:41    [21913530]     Ответить | Цитировать Сообщить модератору
 Re: трипл-таер архитектура (но не совсем) контроллер->сервис->репозиторий  [new]
PetroNotC Sharp
Member

Откуда:
Сообщений: 2446
andreykaT,
Я тебе даже цифру дал, когда нужен и когда нет.
А ты все одно талдычишь.
23 июн 19, 11:00    [21913535]     Ответить | Цитировать Сообщить модератору
 Re: трипл-таер архитектура (но не совсем) контроллер->сервис->репозиторий  [new]
PetroNotC Sharp
Member

Откуда:
Сообщений: 2446
PetroNotC Sharp
один метод дайМнеХХХ(...
дак один метод у тебя?
23 июн 19, 11:04    [21913536]     Ответить | Цитировать Сообщить модератору
 Re: трипл-таер архитектура (но не совсем) контроллер->сервис->репозиторий  [new]
Андрей Панфилов
Member

Откуда: Москва > Melbourne
Сообщений: 3343
andreykaT
так вот чел который его делал упорно избегал среднего слоя. и фигачил работу с репозиторием прям в контроллере. т.е. вызовы репозитория и какая то там логика была внутри контроллера.
как-то странно кмк, у нас вот наоборот: универсальный контроллер - это десяток классов, а все остальное в сервисах.
23 июн 19, 11:13    [21913540]     Ответить | Цитировать Сообщить модератору
 Re: трипл-таер архитектура (но не совсем) контроллер->сервис->репозиторий  [new]
andreykaT
Member

Откуда:
Сообщений: 2427
можно подробнее? не совсем понял.
23 июн 19, 11:18    [21913543]     Ответить | Цитировать Сообщить модератору
 Re: трипл-таер архитектура (но не совсем) контроллер->сервис->репозиторий  [new]
andreykaT
Member

Откуда:
Сообщений: 2427
я как то был в проекте. там был кстати тоже вроде 4 эндпойнта и всё. остальное они рулили через кейсы. т.е. длиннющая портянка кейсов которая решала на какой сервис уходит запрос. но проект был на тот момент 10+ лет и наерное тогда писали только так :) не знаю чем мотивировали скажем использование этого вместо того чтоб создать новый контроллер с прописанным названием в пути. но вот было такое вот решение.
23 июн 19, 11:20    [21913544]     Ответить | Цитировать Сообщить модератору
 Re: трипл-таер архитектура (но не совсем) контроллер->сервис->репозиторий  [new]
PetroNotC Sharp
Member

Откуда:
Сообщений: 2446
andreykaT
можно подробнее? не совсем понял.
дак любой hello world по контроллеру
23 июн 19, 11:42    [21913550]     Ответить | Цитировать Сообщить модератору
 Re: трипл-таер архитектура (но не совсем) контроллер->сервис->репозиторий  [new]
Озверин
Member

Откуда: Ростов-на-Дону
Сообщений: 5183
andreykaT, у спринга сто лет есть аннотация для репозитораия, которая выставляет его методы через web. Даже контроллер не нужен!! Фигачь прямо в репозитории!

RepositoryRestResource - наше все!

По сути, если проект делает один человек и этот проект довольно примитивный, то можно фигачить что угодно куда угодно.
25 июн 19, 09:28    [21914565]     Ответить | Цитировать Сообщить модератору
 Re: трипл-таер архитектура (но не совсем) контроллер->сервис->репозиторий  [new]
mad_nazgul
Member

Откуда:
Сообщений: 4915
andreykaT
собссно что думаете вы?


ИМХО Слоя приложения определяется доменной моделью которой он оперирует.
Если доменная модель репозитария == доменной модели контроллера, то прокладка в виде сервисного слоя как бы и не нужна.
Явно видно это на примеры элементарных CRUD-приложений, когда слои Controller, Service и Repository ничем друг от друга не отличаются (особенно если использовать Spring Data JPA)
1 июл 19, 11:40    [21917997]     Ответить | Цитировать Сообщить модератору
 Re: трипл-таер архитектура (но не совсем) контроллер->сервис->репозиторий  [new]
PetroNotC Sharp
Member

Откуда:
Сообщений: 2446
mad_nazgul
Явно видно это на примеры элементарных CRUD-приложений, когда слои Controller, Service и Repository ничем друг от друга не отличаются (особенно если использовать Spring Data JPA)
их ещё нет, когды мы задались вопросом, нужны они или нет? Будем их писать или нет?
)))
Поэтому я вас понял, но расплывчато имхо.
1 июл 19, 13:14    [21918090]     Ответить | Цитировать Сообщить модератору
Все форумы / Java Ответить