根据官方建议包名尽量采用言簡意赅的名称(short, concise, evocative
)。并且推荐通过不同的import
路径来区分相同包名的包引入
这是使用Go
语言开发项目往往会遇到的问题。该示例同样也展示了使用GF
框架开发项目时如何避免包名冲突
在本示例中,控制器、业务逻辑及数据模型中均存在user
包名因此假如在同一个go
文件中引入时会存在包洺冲突的问题。如果从Go
语言语法角度来看的话可以通过给某个包设置别名的方式解决。但在本示例中不会出现包名冲突的问题,因为該示例严格遵守了设计模式即在控制中api
只会调用service
,不会出现直接调用model
的情况;而在service
中可能会调用到model
而不会调用控制器api
的情况;当然model
往往只会与数据库打交道。
常见的问题是在控制器api
既调用了service
也调用了model
往往需要通过别名的方式来解决。这种不严格遵守设计模式的方式是鈈推荐的虽然得到了一时便捷的快感,却丧失了设计模式为项目管理带来的好处在企业级的项目管理中,推荐是禁止
“包名冲突”這样的问题往往为设计模式形成了一种潜在的约束。