Как лучше всего удалить "struct" импортные циклы?

Question

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

Структура моего проекта выглядит следующим образом:

model
  orgs
    org.go
  events
    event.go
  shows    
    show.go
  entries
    exhibitor.go
    entry.go
  fees
  premiums
  etc.

Обычно есть 3-8 ходовфайлы в каждой директории листа.В настоящее время под моделью 9 дочерних каталогов.Это будет примерно вдвое.

Вот проблемная часть.Каждый файл .go обычно содержит такую ​​структуру:

import (
    "model/shows"
)
type Event struct {
    ownerOrg *orgs.Org // reference back to the sponsoring organization
    showList []*Show   // list of each show in the event
}

.

import (
    "model/entries"
    "model/events"
)
type Show struct {
    ownerEvent    *events.Event               // reference back to the owner event
    exhibitorList []*entries.Exhibitor // list of exhibitors entered in the show
}

.

import (
    "model/shows"
)
type Exhibitor struct {
    ownerShow *shows.Show            // reference back to the owner show
    entryList []*entries.Entry // list of entries for this exhibitor
}

Наличие обратной ссылки и списка рассылки даетПроблемы с циклом.

Примечание: часто в каждой структуре имеется более одной ссылки на тип «владелец» и почти всегда в каждой структуре более одного среза «список».Это только усугубляет проблему.

Вот то, что я пробовал, и мое лучшее текущее решение (что хорошо, но не очень хорошо).

1. Факторинг для интерфейсов. Это «типичное» решение цикла импорта, которое я вижу.Это кажется неуместным (или даже невозможным?), Когда проблема структурная , а не поведенческая .

2. Изменить "владельцы "должны быть интерфейсами. Я почти уверен, что смогу заставить это работать, но, похоже, приведет к ухудшению структуры.Было бы много преобразований типов и выделение поведения в странные файлы .go.Код больше не «рядом», где он ожидается или используется.Это оставило бы меня с тем, что я бы посчитал сложной структурой, которую другие кодировщики могли бы понять и использовать без какой-либо выгоды, кроме как для того, чтобы компилятор был доволен.

3. Большой шарmud. Просто поместите все 50+ .go файлов в один пакет.Это решает проблему цикла, но создает проблемы читабельности и понимания.

4. Неортодоксальные префиксы. (Мое текущее мышление.) Я могу комбинировать большой шарик спрефиксы каталогов, так что я получаю следующую структуру:

.

model
  orgs_org.go
  events_event.go
  shows_show.go
  entries_exhibitor.go
  entries_entry.go
  etc.

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

Есть ли лучший способ "идти по пути", который кто-нибудь знает для этой (типичной для меня) структуры бизнес-объекта?