@nano_e_t_4

Как выстроить архитектуру приложения?

Всем привет

Периодически занимаюсь разработкой, и недавно попросили сделать простеньйкий бэкенд для сервиса кафе. Суть в том, что на страничке должны отображаться блюда с фотографиями.
Со стороны бэкэнда сделал функционал добавления\изменения\удаления данных из баз и написал http обертку для этого. Но вот текущая архитектура не очень нравится, а именно:

Есть структура еда:
type Food struct {
	Id 				int			`validate:"required"	gorm:"primary_key:true"`
        Name 			string		`validate:"required" 	gorm:"column:name;unique"`
       ....
}


Есть структура Категория (супы\салаты\напитки\горячие блюда и так далее):
type Categories struct {
	Id 				int		`gorm:"primary_key:true"`
        Name 			string		`validate:"required" 	gorm:"column:name;unique"`
        ....
}


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

server_api:
r.Route("/food/", func (r chi.Router) {
			r.Post("/add", AddFood)
			r.Post("/update", UpdateFood)
			r.Post("/delete", DeleteFood)
		})

		r.Route("/category/", func (r chi.Router) {
			r.Post("/add", AddCategorie)
			r.Post("/update", UpdateCategorie)
			r.Post("/delete", DeleteCategorie)
		})


controllers:

func AddFood|AddCategorie(w http.ResponseWriter, r *http.Request) {
       result := food|categorie.Validate()
       food|categorie.Save()
}

func UpdateFood|UpdateCategorie(w http.ResponseWriter, r *http.Request) {
       result := food|categorie.Validate()
       food|categorie.Update()
}

func DeleteFood|DeleteCategorie(w http.ResponseWriter, r *http.Request) {
}


и логика непосредственно взаимодействия с базой данных:
func (f Food|Categorie) Save() (result Result){
return
}
func (f Food|Categorie) Update() (result Result){
	return
}
func (f Food|Categorie) Delete() (result Result){
	return
}


но очень смущает факт большого количества дублирования кода (в том числе дублирование функции валидации). Потому что логика работы обеих структур весьма идентична. Подскажите, как можно реализовать все это менее объемно

p/s
думаю, что тут как нельзя кстати подойдут интерфейсы, но не совсем понимаю, как именно их встроит, ведт интерфейсы реализуют абстрацию, а у меня именно сам функционал очень похож
  • Вопрос задан
  • 518 просмотров
Пригласить эксперта
Ответы на вопрос 1
@grinat
И нафига тебе рест на го для этого?) Исходя из тз, даже просто html файлов хватит. Гоу он для чего-то высоконагруженного, а не потому что модно, он с orm будет работать по скорости на уровне какого-нить пэхэпэ, потому что к примеру они все делают мэпинг, тянуть рэлейшены и т.п. через рефлекты, разные костыли . Вот если тебе надо выдрать из бд миллион записей и сотворить с ними страшные и жуткие вещи, то тут го раскроется.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы