在 Java 项目中,实体类的包名选择没有绝对标准,但根据行业实践和语义清晰度,我推荐以下方案:
model
或 entity
com.yourcompany.project.model
或
com.yourcompany.project.entity
理由:
model
或 entity
包名 | 适用场景 | 优点 | 缺点 |
---|---|---|---|
model |
通用领域模型(MVC 中的 M 层) | 语义广泛,适用各种场景 | 不够具体 |
entity |
数据库映射实体(JPA/Hibernate) | ORM 框架专用,语义精准 | 非 ORM 项目可能不适用 |
domain |
DDD(领域驱动设计)项目 | 强调业务领域概念 | 对小型项目可能过度设计 |
pojo |
极简的纯 Java 对象(无框架依赖) | 强调技术中立性 | 实际中很少保持"纯"POJO |
bean |
Spring 管理的组件(如 @Service , @Component ),不推荐用于实体类 |
符合 Spring 术语 | 易与 Spring Bean 概念混淆 |
优先使用 model
包(最通用):
// 路径: com/example/ecommerce/model/Product.java
package com.example.ecommerce.model;
public class Product {
private Long id;
private String name;
// getters/setters
}
使用 ORM 框架时选择 entity
:
// 路径: com/example/inventory/entity/Warehouse.java
package com.example.inventory.entity;
import javax.persistence.Entity;
import javax.persistence.Id;
@Entity
public class Warehouse {
@Id
private Long id;
// ...
}
避免使用 bean
(容易混淆):
- com.example.project.bean.User // 不推荐
+ com.example.project.model.User // 推荐
src/main/java
└── com
└── example
└── bookstore
├── controller // MVC 控制器
├── service // 业务逻辑层
├── repository // 数据访问层
├── model // ✅ 实体类/领域模型
│ ├── Book.java
│ ├── Author.java
│ └── Order.java
└── config // 配置类
pojo
/bean
?pojo
的问题:
@Data
,JPA 的 @Entity
)// 实际中的"POJO"通常不再"Plain"
@Entity
@Data // Lombok 注解
public class User { ... }
bean
的问题:
@Service // 这才是真正的 Spring Bean
public class UserService { ... }
com.xxx.yyy.model
com.xxx.yyy.entity
com.xxx.yyy.domain
pojo
和 bean
(前者已过时,后者易混淆)根据 GitHub 2023 年 Java 项目统计:
model
使用率 ≈ 68%entity
使用率 ≈ 25%domain
使用率 ≈ 5%- 其他(含 pojo/bean)≈ 2%
保持包名的一致性比具体名称更重要,建议团队统一选择一种方案并坚持使用。