项目目录结构|为什么?

时间:2019-06-27 13:19:30

标签: java kotlin project-structure

主要问题

我想知道为什么目录结构(例如基于Java或Kotlin等的)项目是:

  • src/main/java/com/yemreak/appname/
  • src/test/java/com/yemreak/appname/
  • src/main/resources

我猜想

  • src表示源目录
  • main表示主目录
  • test表示测试目录
  • java表示此目录中文件的语言
  • com.author.appname是指应用的网络域

我在想什么

  • 该结构背后的主要思想是什么?
  • 为什么有那么多目录?通常comauthor目录是空的,为什么要创建它们?
  • 为什么不像基于vscode projectsrc那样使用基于Javascript的脚本,或者为什么它们(他们在不同语言的项目上工作)使用不同的结构? (我知道“ js!= java

额外

项目中有很多目录,

  • services,API的源代码或其他外部代码(例如github API)
  • views,应用的GUI代码
  • models,应用程序的后端代码
  • controllers,控制视图和模型的源代码
  • resources,其他资源(如图像,声音等)

还有其他目录结构吗?

2 个答案:

答案 0 :(得分:4)

  

结构背后的主要思想是什么?

简单地说:这是一个约定。有关更详细的说明,您可能需要查看所有内容的开始位置:Maven和后来的其他内容,包括Gradle(这是您最有可能使用的内容)。

  

为什么有那么多目录?

上一点的文章应该已经解释了为什么其中有一些目录。至于其他不在Maven / Gradle范围内的东西:完全由您决定。如果您热衷于以有意义的方式对事物进行分组,以使您和其他人更容易浏览项目源,并有可能更快地加快事物的处理速度,那就太好了!否则,只需将所有内容堆放在一个目录下就可以玩得开心。

  

com和author dirs通常为空,那么为什么要创建它们?

     

为什么不仅仅让src像基于Javascript的vscode项目一样,还是为什么它们使用不同的结构?

看到com.acme样式结构的原因是因为它也是Java世界中的一个很好的约定,有助于避免(或大大减少)名称冲突(例如:假设您定义了{{ 1}}项目根目录中的类,其中包含所需的所有令人惊叹的数学相关辅助方法;让我们假设您现在想将事情提升到一个新水平,并开始在项目中使用一些疯狂的物理方法,而不是“重新发明” “滚轮”,您决定使用由其他人开发且非常流行且经过时间考验的滚轮;现在,让我们假设第3方库还在其根目录中定义了自己的Math类...其中{{现在,一旦在代码中的某个地方进行Math调用,现在应该使用1}}类吗?它应该使用您定义的类还是3rd party库附带的类呢?标识为位于根目录中的同一位置。)

有关更多信息,请参阅the official Oracle documentation

编辑:

  

还有其他目录结构吗?

实际上,有很多方法可以组织代码。您可以阅读有关here的某些可能方式的信息。但是,归根结底,这取决于个人喜好(特别是如果您是一个人工作)或CTO /团队希望您遵循的任何风格,因为这就是该给定组织应该做的事情。 >

您作为示例给出的样式(“按类型/种类对代码进行分组/分组”)非常普遍,尤其是在经验不足的开发人员中,随着系统变得越来越大,它的崩溃速度很快(想象一下拥有数十个,“模型”包中的数百个模型类,现在不得不在不知道其确切名称的情况下找到您感兴趣的一个模型...或拥有数十个,数百个服务或存储库等。它也没有给出任何指示有关组件之间可能存在哪些可能的相互依存关系,哪些组件与哪些其他组件相关以及更多)。

将代码分离/分组到不同且有意义的包中只是开始,很快,您会发现自己也希望将代码分离到不同的模块中(例如:将与Web相关的代码与业务逻辑分开,或提取公共代码以便可以在多个模块和项目等之间共享,等等。

答案 1 :(得分:0)

您已经回答了您的问题。原因是惯例。如果您不遵循约定编写代码,那么其他人将很难理解它。 例如,当某人看到“服务”目录时,他会假定其中包含一些服务代码。

  

为什么有那么多目录?通常com和作者目录为空,因此   为什么创建它们?

在多模块项目中区分文件。