Как правильно организовать связь модель-модель в MVC?

Question

[neronru]

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

type A struct {
 Id uint64
 Param1 uint
}
type B struct {
Id uint64
IdA uint64
Param2 uint
}
func (b *B) SetParam2(a A) {
b.Param2 =  3*a.Param1
}

В общем, интересует вопрос является ли такой код правильным с точки зрения паттерна MVC?
И получается инициализацию структуры A для дальнейшего использования в B надо производить в контроллере? Или это можно делать в модели B?

Comments

[copal]

чисто по парадигме пофигу как модели получат друг на друга ссылки.

Answer 1

[Никита]

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

Я б сделал не SetParam2, а

type B struct {
  A
  Id uint64
  IdA uint64
  //Param2 uint 
}

func (b B) Param2() uint {
  return A.Param1 * 3;
}

но это, конечно, зависит от задачи.

Для полной ясности проще всего (в смысле не задумываясь над тем как надо) можно создать 3ю структуру С, которая работает с моделями А и B. Инициализация С в контроллере, инициализация А и B в модели С.

Comments

[neronru]

Кстати, да. По-поводу вашего последнего предложения, у меня была идея запилить helper.

[Oleg Shevelev]

func (b B) Param2() uint {
return A.Param1 * 3;
}

Вы тут подразумеваете что A - это "статичный объект" в общем адресном пространстве. Вы так и себя запутаете и программу в конечном итоге.

Суть MVC в том что бы разбивать код на логические составляющие:
Modul - в идиологии Golang это могут быть пакеты которые отвечают за работу с конкретными данными, например отдельно пакет user, post, message и прочие, при этом каждый пакет имеет свой интерфейс наружу - для получения пользователей, для сохранения пользователей, для создания пользователей и так далее
View - это по сути шаблонизатор и обвязка вокруг него, например если у вас есть пакет tmpl то у него вероятно есть метод view(address string, data interface{}), вызвали в контроллере tmpl.view("index.html", data) где нужно и получили готовую отрендеренную страницу
Controller - это по сути стопка функций у которых на вход http.Response, *http.Request и может быть ещё что-то специализированного, вроде контекста где указатель на текущего пользователя и какие-то дополнительные ресурсы, по сути типичные хандлеры для http

А то что было описано в вопросе - это не напоминает MVC никак.

[Никита]

Oleg Shevelev: Не modul, а model(модель), надеюсь что вы очепятались. Мы говорим об одном и том же, разными словами и большинство написанное вами - верно. Я не подразумеваю, что A - это "статичный объект", A - это собственная реализация (объект) структуры А без своего имени, в пространстве структуры B.

[Oleg Shevelev]

Никита: Да, точно:) model:) Видимо сказывается желание сделать модульность к Golang:)

Про A, B - просто слишком мало данных и слишком не информативные названия что бы вообще понять что там и зачем:) Вот об этом и говорил:)

[neronru]

A, B это динамические объекты, причем разной природы.... Но этот вопрос я уже решил.

Answer 2

[Анатолий]

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