Question

我正在将需要重写的旧项目转换为Go。我最初的大多数尝试都看起来很成功，但是我遇到了导入周期问题。

我的项目结构如下：

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

每个叶目录中通常有3-8个go文件。当前在模型下有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
}

具有后向参考和正向列表给了我周期问题。

注意：每个结构中通常有一个以上的“所有者”类型引用，而每个结构中几乎总是有一个以上的“列表”切片。这只会使问题复杂化。

这是我尝试过的，也是我目前最好的解决方案（可以，但不太好用）。

接口的基础。 这是我看到的“通常”导入周期解决方案。当问题是结构性而不是行为时，这似乎不合适（甚至可能？）。
将“所有者”更改为界面。 我很确定这可以使它正常工作，但似乎会导致结构变差。它会进行很多类型转换，并将行为分解为怪异的.go文件。代码不再在“预期”或“使用”的地方。这会让我觉得其他人很难理解和使用它的结构，除了使编译器满意之外，没有其他好处。
大泥巴泥。 只需将所有超过50个.go文件放入一个包中即可。这样可以解决周期问题，但会产生可读性和理解性问题。
非正统前缀。（我目前的想法。）我可以将big-o-mud与目录前缀结合使用，因此最终得到以下结构：

。

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

除了没有看到它，它真的很可怕还是“奇怪”？它似乎确实解决了我的问题，并且将功能保持在预期的位置和使用的位置。

对于这种（通常是我来说）业务对象结构，有人知道一种更好的“行进方式”吗？

如何最好地消除“结构”导入周期？

0 个答案: