Size: a a a

2020 June 06

/

/dev/null in Go-go!
Anton Kucherov
Ну и да, я не отрицаю, что возможно того же Мартина, нужно читать имея за плечами определенный опыт, и что вполне возможно то о чем он пишет может повредить при отсутствии опыта.
Да соглашусь, если читать труд Боба то "не подготовленный ум" может сделать не правильные выводы из этого.
источник

Н

Никита in Go-go!
/dev/null
Посмотрите сюда.
https://github.com/golang-standards/project-layout
Это не священный Грааль но стоит посмотреть на этот подход.
Тут чисто о корневой структуре. У вас только в этом вопрос по поводу того проекта?
источник

Y

Yury in Go-go!
всем привет! а кто-нибудь юзает athens?
источник

VL

V L in Go-go!
Никита
Тут чисто о корневой структуре. У вас только в этом вопрос по поводу того проекта?
Если вам интересно мое мнение, то в вашем MVC меня смущает наличие main.go в каждом пакете, в которых находится немножко другое. Также странно читать поля типа
storage storage.Storage

, всё-таки это конкретное хранилище и было бы имхо лучше  именовать по сущности, контроллер по use-case, пресентер по типу API.
источник

/

/dev/null in Go-go!
Никита
Тут чисто о корневой структуре. У вас только в этом вопрос по поводу того проекта?
Нет. Изучите внимательнее этот репозиторий и посмотрите доклады которые там представлены.
источник

/

/dev/null in Go-go!
V L
Если вам интересно мое мнение, то в вашем MVC меня смущает наличие main.go в каждом пакете, в которых находится немножко другое. Также странно читать поля типа
storage storage.Storage

, всё-таки это конкретное хранилище и было бы имхо лучше  именовать по сущности, контроллер по use-case, пресентер по типу API.
use-case именно про этот карго культ я выше и говорил.
источник

/

/dev/null in Go-go!
Все отстал, не буду дальше развивать эту тему)
источник

VL

V L in Go-go!
/dev/null
use-case именно про этот карго культ я выше и говорил.
Use-case - это карго культ?
источник

AK

Anton Kucherov in Go-go!
Да просто все о чем говорит Мартин воспринимают буквально и переносят 1 в 1 код. Хотя он говорит об абстракциях. Их нужно научиться понимать и видеть в коде, а не пытаться выразить кодом As-Is
источник

/

/dev/null in Go-go!
Anton Kucherov
Да просто все о чем говорит Мартин воспринимают буквально и переносят 1 в 1 код. Хотя он говорит об абстракциях. Их нужно научиться понимать и видеть в коде, а не пытаться выразить кодом As-Is
+
источник

/

/dev/null in Go-go!
V L
Use-case - это карго культ?
да
источник

VL

V L in Go-go!
/dev/null
да
А не могли бы пояснить, потому что для меня это термин из чистой архитектуры дядям Боба.
источник

/

/dev/null in Go-go!
Anton Kucherov
Да просто все о чем говорит Мартин воспринимают буквально и переносят 1 в 1 код. Хотя он говорит об абстракциях. Их нужно научиться понимать и видеть в коде, а не пытаться выразить кодом As-Is
вот тут Антон очень хорошо пояснил
источник

Н

Никита in Go-go!
V L
Если вам интересно мое мнение, то в вашем MVC меня смущает наличие main.go в каждом пакете, в которых находится немножко другое. Также странно читать поля типа
storage storage.Storage

, всё-таки это конкретное хранилище и было бы имхо лучше  именовать по сущности, контроллер по use-case, пресентер по типу API.
В main.go я кидаю основное. На примере Бд, там находится и реализация сервиса. Да, возможно стоит именовать и такое получше, чтобы было понятно, что в файле.

А вот по поводу storage storage.Storage, тут же интерфейс, и конкретная реализация скрыта для бизнес логики. Поэтому в контроллере такое. Если бы можно было импортировать конкретные структуры с пакета, то объявление выглядело бы менее многословным)
источник

/

/dev/null in Go-go!
Никита
В main.go я кидаю основное. На примере Бд, там находится и реализация сервиса. Да, возможно стоит именовать и такое получше, чтобы было понятно, что в файле.

А вот по поводу storage storage.Storage, тут же интерфейс, и конкретная реализация скрыта для бизнес логики. Поэтому в контроллере такое. Если бы можно было импортировать конкретные структуры с пакета, то объявление выглядело бы менее многословным)
>В main.go я кидаю основное.
main это точка входа в программу, ничего больше
источник

VL

V L in Go-go!
Никита
В main.go я кидаю основное. На примере Бд, там находится и реализация сервиса. Да, возможно стоит именовать и такое получше, чтобы было понятно, что в файле.

А вот по поводу storage storage.Storage, тут же интерфейс, и конкретная реализация скрыта для бизнес логики. Поэтому в контроллере такое. Если бы можно было импортировать конкретные структуры с пакета, то объявление выглядело бы менее многословным)
Интерфейс отвечает за действие, так что вам бы подошли NotesSaver, NotesReader
источник

Н

Никита in Go-go!
V L
Интерфейс отвечает за действие, так что вам бы подошли NotesSaver, NotesReader
Ну и как абстракция над конкретной реализацией
источник

VL

V L in Go-go!
И не стоит зависеть от интерфейса от соседнего пакета. Интерфейсы, которые необходимы для работы вашего контроллера должен определять сам контроллер, а не существующая реализация хранилища
источник

Н

Никита in Go-go!
/dev/null
>В main.go я кидаю основное.
main это точка входа в программу, ничего больше
main в корне это и делает. Вообще вопрос нейминга мне не принципиален, так что если есть идеи как сделать его проще, то исправлю
источник

/

/dev/null in Go-go!
Никита
main в корне это и делает. Вообще вопрос нейминга мне не принципиален, так что если есть идеи как сделать его проще, то исправлю
main не должен быть у вас в каждом пакете
источник