【问题标题】:Identical package names in different folders for same project同一项目的不同文件夹中的相同包名称
【发布时间】:2017-04-08 15:05:37
【问题描述】:

我正在做一个大项目,最终可能包含数万行代码,对于当前的结构,我喜欢这样:

main.go
controllers/NAME.go
models/NAME.go

问题在于控制器和模型目录包含很多文件,所有文件都使用package controllerspackage models。因此,我正在考虑像这样拆分它:

main.go
controllers/user/NAME.go
models/user/NAME.go

控制器包中的用户文件可能包含routes.goprofile.go等文件。

现在,我了解到将包命名为 controllersUsercontrollers_user 是一种不好的做法,但我担心将两者都命名为 package user 可能是个坏主意,因为它们是同一个项目的一部分(即使它们位于不同的目录中)。

根据我的情况,你会推荐什么样的命名结构?

我意识到位于控制器/用户中的文件将无法与模型/用户交互,即使它们共享相同的package user 名称(当然,除非我导入),而且我也知道我可以轻松导入userControllers "controllers/user"userModels "models/user",但我想知道这样做是不是一种不好的做法?

【问题讨论】:

    标签: go


    【解决方案1】:

    我建议你阅读style guideline for Go packages。这是一本很棒的读物,包含了我在 Go 中的项目布局方面找到的关于该主题的最佳建议。我很难建议您为您的特定案例命名,因为它过多地取决于您的系统所具有的功能类型。有时,我将其视为“应用程序的每个部分的包”。但我知道我的描述可能过于个人化,没有太大帮助。

    【讨论】:

    • 我同意那篇文章,而且我也能够从个人经验中看出,随着代码库的不断增加,将它们全部放入 controllers 包中将成为一场灾难。但据我所知,拥有两个package user 并没有错,其中一个与其他控制器文件一起放置,另一个与模型文件一起放置?
    • 我认为这与您拥有一个责任包的想法背道而驰。作者在段落中使用用户作为建议。 `package mngtservice` 包含与系统中用户责任相关的所有代码
    • 嗯,一方面我觉得制作一个名为users 的包会很聪明,其中包含router.gomodels.goprofile.goregister.go 等文件。另一方面,这意味着放弃 MVC 结构,我可以很好地将这些目录放在模型和控制器目录中。如果我不能将它们放在控制器/模型目录中,你会建议如何命名包含所有这些网络应用相关功能的目录?
    • 我个人在最近的项目中调用了api。它包含用于设置端点、cors、不同类型请求的所有代码。也许是网络?不过有点太笼统了。起名太难了! :)
    • 哈哈,我考虑过webappmodulesroutes等,但它并没有给我带来与modelscontrollers一样的满足感.. 但是感谢您所做的一切,我认为感谢您,我的项目结构会大大改善:)
    猜你喜欢
    • 2013-12-06
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2012-01-30
    • 1970-01-01
    相关资源
    最近更新 更多