ну и контроллер напиши универсальный какой то работающий над подобным сервисом

гонишься за переиспользованием кода? Хорошее начинание. Используй только отдельные сущности, типа, сервисов

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

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

ну неприятные вещи с оопшностью)

ну неприятные вещи с оопшностью)

не я просто не понял как это на переиспользование кода влияет)

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

или тут про паттерн?

не я просто не понял как это на переиспользование кода влияет)

я сервисы эти строил вокруг орм с дженериками и di, правда, на другом языке

или тут про паттерн?

а хер знает просто сущность вводил дополнительную все функции по работе с БД велись через наследуемый абстрактный сервис, который работал с репозитарием с дженериком модели

ну и контроллер работал над этим сервисом

а хер знает просто сущность вводил дополнительную все функции по работе с БД велись через наследуемый абстрактный сервис, который работал с репозитарием с дженериком модели

ну тут это через интерфейсы)))

понял о чем речь

)))

Вопросик, а go in action у кого-то есть перевод?

или Go in Practice

я для себя летом фреймворк написал на go, хотел что типа symfony (php) на go + чтобы было еще и на gin похоже... все еще пилю потихоньку... если есть желание у кого-то поковырять и покритиковать (документации почти нет, еще не начинал... но кто с gin работал - поймет) Хотелось бы именно по коду получить рекомендации https://github.com/itrabbit/just

за опечатки в тексте и комментах - сорян)))

понял о чем речь

а, еще добавлю в наследник контроллера инжектим сервис над нужной моделью в наследник сервиса с нужной моделью инжектив репозитарий над орм моделью

ну и над всей этой хренью можно споконо написать автогенератор рест апи согласно модели

вот обьясните мне, зачем вообще юзать гоу, если везде вы пишите автогенераторы?

вот обьясните мне, зачем вообще юзать гоу, если везде вы пишите автогенераторы?

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

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

тогда почему бы не взять подходящий язык?

вот обьясните мне, зачем вообще юзать гоу, если везде вы пишите автогенераторы?

слушай , я домой еду ,зачем ты так

тогда почему бы не взять подходящий язык?

если есть задача автогенерации - возможно)))

тогда почему бы не взять подходящий язык?

лично мне разработка на go приносит удовольствие))))

лично мне разработка на go приносит удовольствие))))

садомазо тож любишь?)

садомазо тож любишь?)

нет, на go нет садомазо))) все локанично и просто на пределе возможностей языка))) да и по скорости работы и потреблению ресурсов вполне устраивает...

нет, на go нет садомазо))) все локанично и просто на пределе возможностей языка))) да и по скорости работы и потреблению ресурсов вполне устраивает...

насчело локаничности можно поспорить

насчело локаничности можно поспорить

ну это мое мнение... да и дело привычки)))

asm тоже простой, да и скорость работы хорошая))) только вот лаконичности нет

примерно такой ж довод)

asm не простой)))

синтаксис да

как язык простой

но не все остальное

написать на асме веб микросервис за вечер из коробки нереально

web service на ASM? шта?!

+

гонишься за переиспользованием кода? Хорошее начинание. Используй только отдельные сущности, типа, сервисов

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

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

Дык, а зачем такое разделение делать то?

Дык, а зачем такое разделение делать то?

потому что видимо я что-то не понимаю. вот смотри, у меня Rest, я получаю POST запрос на создание пользователя, при попытке его пихнуть в базу получаю ошибку что такой логин уже есть, т.е. произошла ошибка, мне надо свернуть дальнейшие действия и выдать эту ошибку клиенту. как это сделать правильно? я это вижу как return nil, errors, 500 если же все успешно создано - то return result, nil, 200

но так не выйдет т..к. к следующему хендлеру дойдет очередь толкьо если ретурнов не будет, т.е. мне надо просто дергать метод, но методу для отправки ответа нужен контекст, причем - всегда. но каждый раз добавлять что-то вроде Write(ctx, ...) желания нет, хотя то что придется писать что-то вроде Write(res, errors, port) return я уже смирился( но чем-то этот вариант мне не нравится. может я реально где-то затупил?

потому что видимо я что-то не понимаю. вот смотри, у меня Rest, я получаю POST запрос на создание пользователя, при попытке его пихнуть в базу получаю ошибку что такой логин уже есть, т.е. произошла ошибка, мне надо свернуть дальнейшие действия и выдать эту ошибку клиенту. как это сделать правильно? я это вижу как return nil, errors, 500 если же все успешно создано - то return result, nil, 200

Так это бизнес логика, зачем ее отдельно куда то пихать

Так это бизнес логика, зачем ее отдельно куда то пихать

Т.е. каждый раз писать что-то типа такого это нормально?: func (h *TokenHandler) CreateUser(c *macaron.Context, errs binding.Errors, user model.User) { var lastInsertId int var createdAt time.Time err := h.DBConn.QueryRow("INSERT INTO auth.users(username, password, email) VALUES($1, $2, $3) RETURNING user_id, created_at", user.Username, user.Password, user.Email).Scan(&lastInsertId, &createdAt) if err != nil { errs.Add([]string{}, "users", "Не удалось создать нового пользователя") //.. тут еще ошибки // вот типа такого?? result := Result{ Result: nil, Errors: errs, } c.JSON(500, result) return } user.UserID = lastInsertId user.CreatedAt = createdAt res := map[string]interface{}{ "user": user, } Write(c, res, nil, 200) return //c.JSON(200, res) }

Так то да. Только это приведет к дублированию кода, если понадобится еще где то этот код

я не особо вник, но если нужно что-то в любом случае отправлять, почему не использовать defer?

Так то да. Только это приведет к дублированию кода, если понадобится еще где то этот код

вот оно и приводит, а я не могу понять как правильно это дублирование убрать. в идеале я хочу просто делать return res, err, port и всё

я не особо вник, но если нужно что-то в любом случае отправлять, почему не использовать defer?

хм... потому что данные отправятся которые были на момент вызова Defer? он же так вроде работает?

вот оно и приводит, а я не могу понять как правильно это дублирование убрать. в идеале я хочу просто делать return res, err, port и всё

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

так именно это я хочу сделать, не понимаю как

так именно это я хочу сделать, не понимаю как

Что непонятно?

как из контроллера передать данные в эту отдельную сущность которая их будет отправлять

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

я для себя летом фреймворк написал на go, хотел что типа symfony (php) на go + чтобы было еще и на gin похоже... все еще пилю потихоньку... если есть желание у кого-то поковырять и покритиковать (документации почти нет, еще не начинал... но кто с gin работал - поймет) Хотелось бы именно по коду получить рекомендации https://github.com/itrabbit/just

Прошу прощения, как сообщество гоферов относится к утверждениям о том что мол Rust быстрее Go?

Прошу прощения, как сообщество гоферов относится к утверждениям о том что мол Rust быстрее Go?

И чё?

Давай смотреть через призму построения рест апи. Есть сущность /users. Над ним есть CRUD операции. Создание, чтение, обновление и удаление. Чтение двух видов может быть. /users и /users/:user_id Вот и строй сервис и контроллер согласно такого соглашения

А ничё? Просто хочу узнать мнение.

Прошу прощения, как сообщество гоферов относится к утверждениям о том что мол Rust быстрее Go?

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

Накой мне Раст без сообщества, без кучи либ, с ломающейся совместимостью и без успешных примеров в продакшене?

Get /users?offset=&limit= Get /users/:user_id Post /users Put /users/:user_id Delete /users/:user_id К примеру, от такого рест апи оттолкнись

Давай смотреть через призму построения рест апи. Есть сущность /users. Над ним есть CRUD операции. Создание, чтение, обновление и удаление. Чтение двух видов может быть. /users и /users/:user_id Вот и строй сервис и контроллер согласно такого соглашения

так именно так и делаю

Вечно растровые тролли в Go чатиках ищут чё поесть)

Get /users?offset=&limit= Get /users/:user_id Post /users Put /users/:user_id Delete /users/:user_id К примеру, от такого рест апи оттолкнись

лучше не использовать числовые id для пользователей

Get /users?offset=&limit= Get /users/:user_id Post /users Put /users/:user_id Delete /users/:user_id К примеру, от такого рест апи оттолкнись

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

лучше не использовать числовые id для пользователей

почему

лучше не использовать числовые id для пользователей

а какие? uuid? неее...

почему

перебор проще

перебор проще

перебор по чему конкретно будет быстрее?

ERROR: S client not available

а, все

понял

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

С сервиса в контроллер возвращай (err, result) Если ерр не нил — обработать ошибки. Если неизвестная ошибка — верни с контроллера 500 ошибку

С сервиса в контроллер возвращай (err, result) Если ерр не нил — обработать ошибки. Если неизвестная ошибка — верни с контроллера 500 ошибку

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

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

ты на go фреймворк используешь или на встроеном пакете http?

на фреймворке - macaron

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

Хэндлер запроса один) и это одна из функций круд. Перед ним может быть какие то мидлвеа Этот хэндлер в большинстве своем лишь вызывает метод сервиса и формирует ответ на хттп запрос в зависимости от того что сервис вернет А вся бизнес логика скрыта от контроллера

Хэндлер запроса один) и это одна из функций круд. Перед ним может быть какие то мидлвеа Этот хэндлер в большинстве своем лишь вызывает метод сервиса и формирует ответ на хттп запрос в зависимости от того что сервис вернет А вся бизнес логика скрыта от контроллера

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

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

Не, неправильно совершенно логику в контроллерах держать)

Не, неправильно совершенно логику в контроллерах держать)

я слышал толкьо про логику в контроллерах и в моделях, или есть еще третий вариант?

я слышал толкьо про логику в контроллерах и в моделях, или есть еще третий вариант?

толстая модель, ты имеешь в виду? я хз, так не строил системы

а в каком месте тогда логика? те самые сервисы?

но не в контроллер бы я точно пихал бизнес логику)))

а в каком месте тогда логика? те самые сервисы?

да, сервисы

да, сервисы

т.е. проект выглядит как-то так?: /src/ - db - model - controller - service main.go ?

примерно еще utils могут быть я бы db в папку models засунул ну а там всякие дополнительные структуры можно засунуть в папку structs в папке models

примерно еще utils могут быть я бы db в папку models засунул ну а там всякие дополнительные структуры можно засунуть в папку structs в папке models

Спасибо, щас буду пробовать

но не в контроллер бы я точно пихал бизнес логику)))

а если контроллеры часть сервиса? Просто от фреймворков много чего зависит...

а если контроллеры часть сервиса? Просто от фреймворков много чего зависит...

неправильно теряется переиспользуемость контроллер - это хрень что работает с http сервис - это хрень что отвечает за бизнес логику такое себе разделение ответственности)

не зависит, кстати, от фрейма

в общем подобный подход позволяет быстро и просто перейти от REST к чему другому например как я понял

переиспользование контроллера? скиньте мне паттерн который это описывает)

переиспользование контроллера? скиньте мне паттерн который это описывает)

почему переиспользование?

просто стало интересно)

переиспользуемость именно кода для логики имелась в виду судя повсему

переиспользуемость именно кода для логики имелась в виду судя повсему

вы на php кодили?

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

по крайне мере как я понимаю это дело

переиспользование контроллера? скиньте мне паттерн который это описывает)

сервиса а точнее, бизнес логики

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

про фронт не догнал... вы хотите html выдавать, а иногда json?

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

ну и вполне так тоже)

про фронт не догнал... вы хотите html выдавать, а иногда json?

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