Java 项目的包结构？

Package structure for a Java project?

提问by mawaldne

Whats the best practice for setting up package structures in a Java Web Application?

在 Java Web 应用程序中设置包结构的最佳实践是什么？

How would you setup your src, unit test code, etc?

您将如何设置 src、单元测试代码等？

采纳答案by johnstok

You could follow maven's standard project layout. You don't have to actually use maven, but it would make the transition easier in the future (if necessary). Plus, other developers will be used to seeing that layout, since many open source projects are layed out this way,

您可以遵循 maven 的标准项目布局。您不必实际使用 maven，但它会使将来的转换更容易（如有必要）。另外，其他开发人员会习惯于看到这种布局，因为许多开源项目都是这样布局的，

回答by lycono

There are a few existing resources you might check:

您可能会检查一些现有资源：

1. Properly Package Your Java Classes
2. Spring 2.5 Architecture
3. Java Tutorial - Naming a Package
4. SUN Naming Conventions

1. 正确打包您的 Java 类
2. Spring 2.5 架构
3. Java 教程 - 命名包
4. SUN 命名约定

For what it's worth, my own personal guidelines that I tend to use are as follows:

就其价值而言，我倾向于使用的个人指导方针如下：

1. Start with reverse domain, e.g. "com.mycompany".
2. Use product name, e.g. "myproduct". In some cases I tend to have common packages that do not belong to a particular product. These would end up categorized according to the functionality of these common classes, e.g. "io", "util", "ui", etc.
3. After this it becomes more free-form. Usually I group according to project, area of functionality, deployment, etc. For example I might have "project1", "project2", "ui", "client", etc.

1. 从反向域开始，例如“com.mycompany”。
2. 使用产品名称，例如“myproduct”。在某些情况下，我倾向于使用不属于特定产品的通用包。这些最终会根据这些常见类的功能进行分类，例如“io”、“util”、“ui”等。
3. 在此之后，它变得更加自由。通常我根据项目、功能领域、部署等进行分组。例如，我可能有“project1”、“project2”、“ui”、“client”等。

A couple of other points:

其他几点：

1. It's quite common in projects I've worked on for package names to flow from the design documentation. Usually products are separated into areas of functionality or purpose already.
2. Don't stress too much about pushing common functionality into higher packages right away. Wait for there to be a need across projects, products, etc., and then refactor.
3. Watch inter-package dependencies. They're not all bad, but it can signify tight coupling between what might be separate units. There are tools that can help you keep track of this.

1. 在我从事的项目中，包名从设计文档中流出是很常见的。通常产品已经被划分为功能或目的领域。
2. 不要过分强调立即将通用功能推入更高的包中。等待跨项目、跨产品等有需求，然后重构。
3. 观察包间的依赖关系。它们并不都是坏的，但它可能意味着可能是独立单元之间的紧密耦合。有一些工具可以帮助您跟踪这一点。

回答by pdeva

The way i usually have my hierarchy of folder-

我通常拥有文件夹层次结构的方式-

• Project Name
  • src
  • bin
  • tests
  • libs
  • docs

• 项目名
  • 源文件
  • 垃圾桶
  • 测试
  • 库
  • 文档

回答by dataAnalyst

I would suggest creating your package structure by feature, and not by the implementation layer. A good write up on this is Java practices: Package by feature, not layer

我建议按功能创建包结构，而不是按实现层。对此的一篇很好的文章是Java 实践：按功能打包，而不是按层

回答by dataAnalyst

I usually like to have the following:

我通常喜欢以下内容：

• bin (Binaries)
• doc (Documents)
• inf (Information)
• lib (Libraries)
• res (Resources)
• src (Source)
• tst (Test)

• bin（二进制文件）
• doc（文件）
• inf（信息）
• lib（库）
• 资源（资源）
• 源代码（来源）
• tst（测试）

These may be considered unconventional, but I find it to be a very nice way to organize things.

这些可能被认为是非常规的，但我发现这是一种非常好的组织方式。

回答by Raj

The way I usually organise is
- src
        - main
                - java
                - groovy
                - resources
        - test
                - java
                - groovy
- lib
- build
        - test 
                - reports
                - classes
- doc