Галеру там перед заказчиком пиарили

Не решали короче ничего

Галеру там перед заказчиком пиарили

ключевое слово "перед заказчиком". архтектор на аутсорсе - не самая сладкая работа, архитектор в опенсорс проекте - думаю, вполне хорошая позиция

Аутсорс вообще в целом - такое себе занятие

+

Не хочу больше в аутсорс работать

сейчас работаю в аутсорс

индуский проект на OSGI завезли)) весёлое занятие добавление новых фичей

О:

Аутсорс вообще в целом - такое себе занятие

Лет десять назад аутсорс еще вроде ничего был (субъективно). Тогда слово архитектора еще имело вес.

https://pastebin.com/5wpBEi4V

и так весь проект))

У меня сейчас неплохой проект. Java 8/gradle 4.8/Spring 4.3.17. Покрытие тестами обязательно, статический анализ, интеграционные тесты, код ревью и прочее прочее. И люди в целом неплохие работают. Но все равно как-то не то все равно.

https://pastebin.com/5wpBEi4V

без джава скл дсл грустновато

но в целом понятно, что происходит

Например что-то новое делают в Лондоне, а нам потом передают, как готовое.

Вместо этого гоняем ДТО по слоям сервисов)

Кстати, в сферической Clean Architecture DTO используют для передачи данных между слоями, но так ли необходимо писать отдельный DTO на каждый слой?

Кстати, в сферической Clean Architecture DTO используют для передачи данных между слоями, но так ли необходимо писать отдельный DTO на каждый слой?

там и слоев может не быть

ну или сильно меньше их становится

там и слоев может не быть

Ну берём сферического коня со слоями.

тк у тебя рич обжект берет на себя функционал

DTO для меня хорошо только на границе приложения с внешними системами/источниками данных.

Когда DTO используется в передаче между сферическими сервисами - превращается все в лапшу

тк у тебя рич обжект берет на себя функционал

Кстати, я в своё время на конвертеры перекатился, но вообще не уверен что это как-то правильно с точки зрения теории

конверторы,мапперы)) норм тема

куда лучше, чем toDto, toEntity

у рич обжекта

конверторы,мапперы)) норм тема

ага, проходили: toDto/fromDto

тк по идее тут скрещивание слоев идет

вроде дто слой из EJB пошел или я ошибаюсь?

JavaBeans

java2ee паттерны вроде

есть еще VO - value objects

Самое зло, которое произошло с индустрией)

TO

http://www.oracle.com/technetwork/java/transferobject-139757.html

DTO для меня хорошо только на границе приложения с внешними системами/источниками данных.

Ну вот смотри: есть у нас условный Entity, конкретный объект. Я что-то с ним делаю, а потом отправляю в контроллер и только в контроллере конвертирую в DTO. Но Entity это же ещё и модель данных. Да и как тогда укладывается работа с Repository на слое сервисов, если база данных, так-то, тоже внешний источник данных

Ну вот смотри: есть у нас условный Entity, конкретный объект. Я что-то с ним делаю, а потом отправляю в контроллер и только в контроллере конвертирую в DTO. Но Entity это же ещё и модель данных. Да и как тогда укладывается работа с Repository на слое сервисов, если база данных, так-то, тоже внешний источник данных

ну и каша у тебя в голове

Ну вот смотри: есть у нас условный Entity, конкретный объект. Я что-то с ним делаю, а потом отправляю в контроллер и только в контроллере конвертирую в DTO. Но Entity это же ещё и модель данных. Да и как тогда укладывается работа с Repository на слое сервисов, если база данных, так-то, тоже внешний источник данных

по идее в этом случае у тебя 2 dto на одну сущность - одна для контроллера, вторая для базы

ну и каша у тебя в голове

Скорее я криво пояснил

как одно решение уйти от дто в ресте это graphql

но он и приносит другие проблемы))

Очень сильно не хватает поддержки Mermaid в чятике

Ну вот смотри: есть у нас условный Entity, конкретный объект. Я что-то с ним делаю, а потом отправляю в контроллер и только в контроллере конвертирую в DTO. Но Entity это же ещё и модель данных. Да и как тогда укладывается работа с Repository на слое сервисов, если база данных, так-то, тоже внешний источник данных

ты в контроллер отправляешь уже ДТО

которую ты заворачиваешь уже в http-сущность

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

ты в контроллер отправляешь уже ДТО

И из контроллера извне тоже DTO, но уже другое. Но с базой-то как быть?

И из контроллера извне тоже DTO, но уже другое. Но с базой-то как быть?

а что с бд?

База же тоже внешний источник данных по отношению к нашему приложению

да

только ты кое-что забываешь

А слой сервисов, в куче CRUD-ов, зависит от репозиториев

эта бд понятия не имеет о твоих энтити)

в отличии от внешних систем

с которыми ты по хттп например взаимодействуешь

бд ты должен смаппить свою энтити в скл - любым способом

те в бд не уйдет никакой объект

Когда DTO используется в передаче между сферическими сервисами - превращается все в лапшу

Я одно время тоже так думал, и как компромиссная позиция годится в общем то, но на практике - мне так муторно, например. У себя я вообще забил. Данные - это данные, нечего из них объекты корчить. Опиши я у себя GitHub хук евент как DTOшку, даже с ломбоком получил бы орясину на 100500 строк, из которых мне нужно то от силы десяток полей.

эта бд понятия не имеет о твоих энтити)

Ну погоди, Entity же по-сути модель таблицы. Одна энтити — одна запись.

Ну погоди, Entity же по-сути модель таблицы. Одна энтити — одна запись.

это ты так смаппил

Так.

Сейчас переформулирую: есть репозитории, которые дёргают SQL туда-сюда. И так получается, что слой сервисов зависит от репозиториев. Но база, из/в которую туда-сюда данные в репозиториях гоняются, является внешним источником данных по отношению к нашему приложению.

ну как тебе объяснить - ты энтити эту в бд не отправляешь - какой-либо код генерит из нее скл запрос

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

Это я понимаю

Я про направление зависимостей

ERROR: S client not available

Контроллер -> Сервис -> Репозиторий

Т.е. получается что слой сервисов (бизнес-логики) зависит от внешнего слоя

Хотя по той же Clean Architecture должно быть как-то так: Controller -> Service <- Repository

а как сервис от контроллера зависит?

Наоборот же

Контроллер от него

так он источник данных

для него

Репозиторий для сервиса?

сервис для контроллера

А, ну да

К этой части у меня и нет вопросов

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

Я одно время тоже так думал, и как компромиссная позиция годится в общем то, но на практике - мне так муторно, например. У себя я вообще забил. Данные - это данные, нечего из них объекты корчить. Опиши я у себя GitHub хук евент как DTOшку, даже с ломбоком получил бы орясину на 100500 строк, из которых мне нужно то от силы десяток полей.

Да, так и есть. Ну короче я для себя решил слезать к чертям с Java. Гиблое это дело)

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

репозиторий зависит от сервиса?

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

ну это смотря как дизайнишь приложение: top-to-down или down-to-top

Да, так и есть. Ну короче я для себя решил слезать к чертям с Java. Гиблое это дело)

Так а какие тут больно альтернативы то? Даже если другие языки брать. Данные они и есть данные.

репозиторий зависит от сервиса?

В текущих реализациях — сервис от репозитория зависит. Но ведь по-идее должно быть наоборот

я так не думаю

индуский проект на OSGI завезли)) весёлое занятие добавление новых фичей

лучше на ЕО писать

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

лучше на ЕО писать

Индусский можно писать только на индусском)

если сервис пишется для уже готового репозитария, то танцуем от репы, если они дизайнятся вместе, то репу обычно рисуют под требования сервиса

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

Можешь ссылку дать на статью каноничную?

Можешь ссылку дать на статью каноничную?

Мартин Фаулер - Шаблоны корпоративных приложений

Так тут классическая схема же, где по-итогу сервис имеет репозиторий в зависимостях

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

Это все хорошо звучит. До того момента, когда одному сервису нужна функциональность другого

Мартин Фаулер - Шаблоны корпоративных приложений

Угумс, спасибо за дитературу

народ, как заставить спринговый контроллер вернуть plain text?

@ResponseBody и produces = "text/plain;charset=UTF-8" стоят

народ, как заставить спринговый контроллер вернуть plain text?

вернуть строку и хэдер плэйн текст