DD
это я так завуалированно вас предупредил, что вы собираетесь лепить говнокод
Пока ты нес чушь в группе про Голанг я уже разобрался и написал код
Size: a a a
2020 July 28
DK
Пока ты нес чушь в группе про Голанг я уже разобрался и написал код
😂
MB
Приветствую! Подскажите по общепринятым в Го подходам. Есть цель научиться читать на Go код определенных проектов, для этого в учебных целях делаю тестовый блог, чтобы научиться и самому языку, и общепринятым архитектурным решениям.
Есть простой блог, в нем есть сервисы: user (регистрация, логин, апдейт профайла и т.п.) и post (создания поста, поиск по постам и прочее).
Я вижу тут два варианта к организации этих сервисов:
1) Используем пакеты.
Например пакет user, в нем методы типа Login(), Register(), UpdateProfile() и прочее.
2) Используем структуры и в них создаем методы. Т.е. создаем пакет service, а в нем две структуры UserService и PostService. И уже все эти методы прикручиваем к соотвествующим структурам.
Я начал с первого варианта, т.е. просто исопльзовал пакеты типа user. Но начало раздражать, что у меня из-за того что пакеты называются user и post, переменные приходится называть как-то более сложно и осознанно. А я привык в коротких функциях использовать простые названия просто post. А тут это имя занято уже названием пакета и приходится что-то усложнять.
Какой вы считаете подход более распостраненный для реализации сервисов на Го?
В самих сервисах у меня из внутренних состояний есть лишь коллекция базы данных (монгодб), которая инициализируется при запуске сервера.
Есть простой блог, в нем есть сервисы: user (регистрация, логин, апдейт профайла и т.п.) и post (создания поста, поиск по постам и прочее).
Я вижу тут два варианта к организации этих сервисов:
1) Используем пакеты.
Например пакет user, в нем методы типа Login(), Register(), UpdateProfile() и прочее.
2) Используем структуры и в них создаем методы. Т.е. создаем пакет service, а в нем две структуры UserService и PostService. И уже все эти методы прикручиваем к соотвествующим структурам.
Я начал с первого варианта, т.е. просто исопльзовал пакеты типа user. Но начало раздражать, что у меня из-за того что пакеты называются user и post, переменные приходится называть как-то более сложно и осознанно. А я привык в коротких функциях использовать простые названия просто post. А тут это имя занято уже названием пакета и приходится что-то усложнять.
Какой вы считаете подход более распостраненный для реализации сервисов на Го?
В самих сервисах у меня из внутренних состояний есть лишь коллекция базы данных (монгодб), которая инициализируется при запуске сервера.
DD
это рофл?) вместо того чтобы юзать проверенный годами стабильный, безопастный и всеми известный nginx - писать свой лисапед)
Я понимаю у тебя проблемы с интеллектом но в следующий раз подумай что не все такие примитивные как ты. Если бы мне надо было решение на нгинкс хапрокси или траефике или кадди или любом сраном роутере я бы пошел в группу про роутеры. Андерстанд чукча?
RR
Вот, стазу чатик го узнаётся
B
Я понимаю у тебя проблемы с интеллектом но в следующий раз подумай что не все такие примитивные как ты. Если бы мне надо было решение на нгинкс хапрокси или траефике или кадди или любом сраном роутере я бы пошел в группу про роутеры. Андерстанд чукча?
ахаха какое животное) твое сообщение говорит лишь о том что тебе нужен был роутер "посадить несколько сайтов на один http порт" так что либо ты не до конца описал свой кейс либо написал велосипед и тешишь свое эго тем что написал велосипед. А еще скатываешься до оскорблений. Ничего лет через 10 надеюсь подрастешь)
АП
хватит токсить
A
Я понимаю у тебя проблемы с интеллектом но в следующий раз подумай что не все такие примитивные как ты. Если бы мне надо было решение на нгинкс хапрокси или траефике или кадди или любом сраном роутере я бы пошел в группу про роутеры. Андерстанд чукча?
вот это ворвался
DP
Приветствую! Подскажите по общепринятым в Го подходам. Есть цель научиться читать на Go код определенных проектов, для этого в учебных целях делаю тестовый блог, чтобы научиться и самому языку, и общепринятым архитектурным решениям.
Есть простой блог, в нем есть сервисы: user (регистрация, логин, апдейт профайла и т.п.) и post (создания поста, поиск по постам и прочее).
Я вижу тут два варианта к организации этих сервисов:
1) Используем пакеты.
Например пакет user, в нем методы типа Login(), Register(), UpdateProfile() и прочее.
2) Используем структуры и в них создаем методы. Т.е. создаем пакет service, а в нем две структуры UserService и PostService. И уже все эти методы прикручиваем к соотвествующим структурам.
Я начал с первого варианта, т.е. просто исопльзовал пакеты типа user. Но начало раздражать, что у меня из-за того что пакеты называются user и post, переменные приходится называть как-то более сложно и осознанно. А я привык в коротких функциях использовать простые названия просто post. А тут это имя занято уже названием пакета и приходится что-то усложнять.
Какой вы считаете подход более распостраненный для реализации сервисов на Го?
В самих сервисах у меня из внутренних состояний есть лишь коллекция базы данных (монгодб), которая инициализируется при запуске сервера.
Есть простой блог, в нем есть сервисы: user (регистрация, логин, апдейт профайла и т.п.) и post (создания поста, поиск по постам и прочее).
Я вижу тут два варианта к организации этих сервисов:
1) Используем пакеты.
Например пакет user, в нем методы типа Login(), Register(), UpdateProfile() и прочее.
2) Используем структуры и в них создаем методы. Т.е. создаем пакет service, а в нем две структуры UserService и PostService. И уже все эти методы прикручиваем к соотвествующим структурам.
Я начал с первого варианта, т.е. просто исопльзовал пакеты типа user. Но начало раздражать, что у меня из-за того что пакеты называются user и post, переменные приходится называть как-то более сложно и осознанно. А я привык в коротких функциях использовать простые названия просто post. А тут это имя занято уже названием пакета и приходится что-то усложнять.
Какой вы считаете подход более распостраненный для реализации сервисов на Го?
В самих сервисах у меня из внутренних состояний есть лишь коллекция базы данных (монгодб), которая инициализируется при запуске сервера.
Пакеты, структуры и интерфейсы распространены :)
Это большая тема, но, если коротко, можно ориентироваться на удобство тестироаания
Это большая тема, но, если коротко, можно ориентироваться на удобство тестироаания
MB
Пакеты, структуры и интерфейсы распространены :)
Это большая тема, но, если коротко, можно ориентироваться на удобство тестироаания
Это большая тема, но, если коротко, можно ориентироваться на удобство тестироаания
Я еще столкнулся с проблемой циклических импортов. Т.е. у меня в пакете user есть вызовы из пакета post, и в пакете post есть вызовы из пакета user. Как я понимаю это ж не разрулить просто?
В таком случае все держать в одном пакете service и делать структуры UserService, PostService — выглядит как решение.
В таком случае все держать в одном пакете service и делать структуры UserService, PostService — выглядит как решение.
DP
Я понимаю у тебя проблемы с интеллектом но в следующий раз подумай что не все такие примитивные как ты. Если бы мне надо было решение на нгинкс хапрокси или траефике или кадди или любом сраном роутере я бы пошел в группу про роутеры. Андерстанд чукча?
Увидел бы сразу - прописал бы RO
Не надо так
Не надо так
DP
Я еще столкнулся с проблемой циклических импортов. Т.е. у меня в пакете user есть вызовы из пакета post, и в пакете post есть вызовы из пакета user. Как я понимаю это ж не разрулить просто?
В таком случае все держать в одном пакете service и делать структуры UserService, PostService — выглядит как решение.
В таком случае все держать в одном пакете service и делать структуры UserService, PostService — выглядит как решение.
Скорее - пакетов должно стать больше, а не меньше.
Точки пересечения уносятся в отдельные пакеты
Точки пересечения уносятся в отдельные пакеты
АД
Я еще столкнулся с проблемой циклических импортов. Т.е. у меня в пакете user есть вызовы из пакета post, и в пакете post есть вызовы из пакета user. Как я понимаю это ж не разрулить просто?
В таком случае все держать в одном пакете service и делать структуры UserService, PostService — выглядит как решение.
В таком случае все держать в одном пакете service и делать структуры UserService, PostService — выглядит как решение.
зачем в UserService посты, если там в нем методы типа Login(), Register(), UpdateProfile()?
DP
Но апломб свидетелей энджиникс подбешивает, да :)
ШН
Посоны, есть такой код (куча такого):
P.S.: Я в курсе, что ошибки нужно проверять, а не скипать.
defer kek.Puk()
при этом kek.Puk() возвращает error
Нормально ли делать так: defer func() { _ = kek.Puk() }()?P.S.: Я в курсе, что ошибки нужно проверять, а не скипать.
DP
А зачем так делать? Чтобы goland не ругался?
Я просто на эту ругань забиваю
Я просто на эту ругань забиваю
В
Парни, я освоил наконец-то GO! Секрет успеха лишь в том, что бы каждый вечер катать с друзьями в кс го
ШН
А зачем так делать? Чтобы goland не ругался?
Я просто на эту ругань забиваю
Я просто на эту ругань забиваю
Да, чтобы не ругался (ворнинг пока что в IDE)