It is recommended to optimize the naming

[tianxia0079]

Description

比如从entity开始有个user. 1 controller层的go可以统一规范为: userController 2 logic层的go可以统一规范为:userLogic 其他类似

否则,现在很多层的都叫user,开发工具里找起来极其费力. 希望可以参考一下java的命名规则,还是很方便的.

Additional

No response

[Issues-translate-bot]

Bot detected the issue body's language is not English, translate it automatically. 👯👭🏻🧑‍🤝‍🧑👫🧑🏿‍🤝‍🧑🏻👩🏾‍🤝‍👨🏿👬🏿

---

Description

For example, starting from entity there is user. 1 Go at the controller layer can be unified and standardized as: userController 2 Go at the logic layer can be unified and standardized as: userLogic Other similar

Otherwise, many layers are now called user, and it is extremely difficult to find them in development tools. I hope you can refer to the Java naming rules, which is very convenient.

Additional

No response

[gqcn]

@tianxia0079 再使用Go进行业务开发的时候，确实会遇到这样的痛点，不是没有想过你提的方案，但是在Go里面，Go官方并不推荐这么做，而是通过不同的import path来区分不同的包。因此GoFrame也沿用了Go官方的开发建议，并没有这么设计。还有另一方面原因，在通过使用GoFrame框架建议的工程规范来开发业务项目，这样的痛点其实也不是很明显。

[Issues-translate-bot]

Bot detected the issue body's language is not English, translate it automatically. 👯👭🏻🧑‍🤝‍🧑👫🧑🏿‍🤝‍🧑🏻👩🏾‍🤝‍👨🏿👬🏿

---

@tianxia0079 When using Go for business development, you will indeed encounter such pain points. It’s not that I haven’t thought about the solution you proposed, but in Go, Go officials do not recommend this, but use different import paths to distinguish between different packages. Therefore, GoFrame also follows Go's official development recommendations and is not designed this way. There is another reason. When developing business projects using the engineering specifications suggested by the GoFrame framework, such pain points are actually not very obvious.