Комментарии 16
Лучше это всё прямо в яве и оставлять.
Зачем оно гошникам?
Не говоря уж про gorm.
Зачем оно гошникам?
Не говоря уж про gorm.
Разве
`json:"id" gorm:"primary_key"` уже не нарушает принципы чистой архитектуры? В бизнес сущность тащим логику отображения и хранения
По размещению файлов и директорий в проекте существует довольно популярное "соглашение" в виде golang-standards/project-layout — крайне рекомендую ознакомиться
Крутая архитектура, особенно когда у нас есть два разных файла sqlHandler.go в папке infrastructure, и sql_handler.go в папке database. И два файла user_repository.go в разных папках.
А это вообще выглядит как мем:
domain — Entities
usecase — Use Cases
interface — Controllers Presenters
infrasctructure — External Interfaces
Больше абстракций и терминов богу терминов?
Руки бы оторвать за такой CLEAN подход.
Один хороший человек(кажется его звали Дэйв) как-то сказал, что любой пакет, если его имя не cmd или internal, должен содержать код, в вашем пакете interfaces я не вижу кода. Так же, этот хороший человек писал, что имя пакета должно отображать назначение, а не содержимое. За отсутствие возможности конфигурировать порт для апишки и данные для соединения с базой хочется выдать отдельный жирный минус. Ну и конечно же, GORM — величайшее зло.
Кстати, вышел GORM 2, по производительности приближен к database/sql. Рефлексия, да есть.
По поводу, что GORM — зло: подскажите, правильно ли я понимаю, что в Go Entity (как отображение таблиц БД на структуры) не нужны, и нужно делать функции, которые возвращают некие DTO (структуры, не связанные непосредственно с таблицами, а связанные только с данными, которые нужны — то есть это могут быть данные из нескольких таблиц)? А в самих функциях либо чистый SQL, либо квери-билдер типа Squirell.
Это не clean architecture, а dirty s.
Бизнес модели не должны знать про gorm, а тут какие-то аннотации. Почему мы вообще полагаемся на технический слой?
Контроллеры кривые, в го же есть нормальный duck typing:
И теперь мы можем в DI легко связать наш архитектурный слой с репозиторием, и бизнесовый с контроллером.
framework специфичные штуки, от echo как раз можно в архитектурном слое использовать, но не в контроллерах и бизнес домене.
Такой код с interface{}
обычно свидетельствует о костылях, за редкими исключениями. А тут это внезапно бизнес код.
ну т.п., тут куча всякого mess'а, не рекомендую кому-то так делать
Бизнес модели не должны знать про gorm, а тут какие-то аннотации. Почему мы вообще полагаемся на технический слой?
Контроллеры кривые, в го же есть нормальный duck typing:
type Repository {
GetByID(userID int64) (models.User, error)
}
type Controller {
repo Repository
}
func NewController(repo Repository) *Controller {
return &Controller { repo: repo }
}
func (c *Controller) GetUser(userID int64) (response, error) {
user, err := c.repo.GetByID(userID)
if err != nil {
// ..
}
// some logic here
return response, nil
}
И теперь мы можем в DI легко связать наш архитектурный слой с репозиторием, и бизнесовый с контроллером.
framework специфичные штуки, от echo как раз можно в архитектурном слое использовать, но не в контроллерах и бизнес домене.
Такой код с interface{}
Create(obj interface{})
обычно свидетельствует о костылях, за редкими исключениями. А тут это внезапно бизнес код.
ну т.п., тут куча всякого mess'а, не рекомендую кому-то так делать
Подскажите, разве это не нарушение чистой архитектуры?
Выше было написано:
Как контроллер второй круг использует database.SqlHandler с внешнего круга?
func NewUserController(sqlHandler database.SqlHandler) *UserController {Выше было написано:
вы можете снаружи вызывать вещи, объявленные внутри, но вы не можете вызывать вещи, объявленные снаружи, находясь внутри.
Как контроллер второй круг использует database.SqlHandler с внешнего круга?
dsn := "root:password...
написано два раза в разных местах одно и то же
так точно нельзя делать
эта статья перевод с китайского языка чтоли...
они хорошему не научат
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Пишем CRUD-приложение на Go с помощью Mysql, GORM, Echo, Clean Architecture