Size: a a a

2020 March 13

DZ

Dmitry Zherebko in Go-go!
это идет хттп вызов по урлу,
урл находится по сигнатуре метода
источник

N

Nikolay in Go-go!
Dmitry Zherebko
вот как выглдяит интегрейшин для другого кейса
ну вот это уже оверкилл, имхо
источник

DZ

Dmitry Zherebko in Go-go!
Nikolay
кроме того, реализация отправки мыла может быть выкинута и переделана в перспективе
тем более проверка валидности этого кода будет через интегрейшин с бд и запросами на сервис провертся
источник

N

Nikolay in Go-go!
я бы разделил сущности - есть 1) маппинги, 2) хэндлеры, 3) бизнес-логика.

Конкретно в твоем этом случае могло бы быть так:
1) метод GetRoutes и передача их в инстанс API
2) сервис, который наружу отдает хэндлеры, а сам дергает бизнес-логику из интерфейса с имплементацией
3) реализация отправки мыла с интерфейсом MailSender, которую можно в тестах легко подменить на мок, тестируя в итоге отдельно сервис, а отдельно маппинги в юнит-тестах, без всякой нужды в развесистых интеграционных
источник

N

Nikolay in Go-go!
и подобная структура хорошо ложится в DI, если он вдруг понадобится
источник

N

Nikolay in Go-go!
соответственно, взаимодействие с базой тоже вынесено в объект(ы) за интерфейсом с набором методов, и эти объекты можно тестировать, не трогая никак остальные куски приложения
источник

N

Nikolay in Go-go!
там без базы уже не обойтись будет, но, по крайней мере, тесты никак не будут завязаны на связку между всеми компонентами, а только на бизнес-логику
источник

DZ

Dmitry Zherebko in Go-go!
у нас сейчас тестится сервис  и связка всех этих вещей. и там уже поднимается база и хттп сервер с этим ендпоинтом
источник

PT

Pax au Telemanus in Go-go!
@onokonem oneof anyof день кончается а вы просили сегодня потыркать
источник

N

Nikolay in Go-go!
Dmitry Zherebko
у нас сейчас тестится сервис  и связка всех этих вещей. и там уже поднимается база и хттп сервер с этим ендпоинтом
ну это просто смешивание всего в одну кучу получилось. Так можно делать, но зачем, если можно более гибко
источник

N

Nikolay in Go-go!
да и кода не сильно больше получится
источник

N

Nikolay in Go-go!
впрочем, дело ваше :)
источник

DZ

Dmitry Zherebko in Go-go!
Nikolay
я бы разделил сущности - есть 1) маппинги, 2) хэндлеры, 3) бизнес-логика.

Конкретно в твоем этом случае могло бы быть так:
1) метод GetRoutes и передача их в инстанс API
2) сервис, который наружу отдает хэндлеры, а сам дергает бизнес-логику из интерфейса с имплементацией
3) реализация отправки мыла с интерфейсом MailSender, которую можно в тестах легко подменить на мок, тестируя в итоге отдельно сервис, а отдельно маппинги в юнит-тестах, без всякой нужды в развесистых интеграционных
но вообще все так, кроме интерфейса в гет роутс
источник

PF

Petr Filippov in Go-go!
Nikolay
я бы разделил сущности - есть 1) маппинги, 2) хэндлеры, 3) бизнес-логика.

Конкретно в твоем этом случае могло бы быть так:
1) метод GetRoutes и передача их в инстанс API
2) сервис, который наружу отдает хэндлеры, а сам дергает бизнес-логику из интерфейса с имплементацией
3) реализация отправки мыла с интерфейсом MailSender, которую можно в тестах легко подменить на мок, тестируя в итоге отдельно сервис, а отдельно маппинги в юнит-тестах, без всякой нужды в развесистых интеграционных
зачем придумывать что то свое, если можно посмотреть как сделан тот же influxdb
источник

N

Nikolay in Go-go!
Dmitry Zherebko
но вообще все так, кроме интерфейса в гет роутс
имхо, там должно быть два слоя интерфейсов. Примерно так:

WebAPI.GetRoutes() -> ServiceIface -> ServiceImpl -> LogicIface -> LogicImpl
источник

DZ

Dmitry Zherebko in Go-go!
Nikolay
имхо, там должно быть два слоя интерфейсов. Примерно так:

WebAPI.GetRoutes() -> ServiceIface -> ServiceImpl -> LogicIface -> LogicImpl
ну вот сервис интефейс в гет роутс и опустили
источник

DZ

Dmitry Zherebko in Go-go!
гет роутс без сервиса небудут теститься это просто маппинги на транспорт
источник

N

Nikolay in Go-go!
Petr Filippov
зачем придумывать что то свое, если можно посмотреть как сделан тот же influxdb
ну как минимум потому что InfluxDB - ни разу не пример качественного стабильного проекта на моем опыте, уж не знаю, почему. И потому что дизайн простого API сервиса никак не связан с дизайном целой базы
источник

PF

Petr Filippov in Go-go!
Nikolay
ну как минимум потому что InfluxDB - ни разу не пример качественного стабильного проекта на моем опыте, уж не знаю, почему. И потому что дизайн простого API сервиса никак не связан с дизайном целой базы
ты проект смотрел?
источник

N

Nikolay in Go-go!
Petr Filippov
ты проект смотрел?
хуже - я его использовал. Не так важно, насколько красиво он написан, если он плохо работает, верно же?
источник