【发布时间】:2012-01-21 15:30:14
【问题描述】:
我从不需要包的 PHP 开始。我们将在我的工作中使用 Java 构建一个项目,并且我正在考虑架构。该系统将是一个具有 3 个级别的内容管理系统。我们将为所有不同的事物提供各种模型。如果所有模型都在一个包中,是否应该将它们分解为不同的包,并与与其“部分”相关的所有其他功能分组,或者完全是其他东西?
【问题讨论】:
标签: java jakarta-ee models
我从不需要包的 PHP 开始。我们将在我的工作中使用 Java 构建一个项目,并且我正在考虑架构。该系统将是一个具有 3 个级别的内容管理系统。我们将为所有不同的事物提供各种模型。如果所有模型都在一个包中,是否应该将它们分解为不同的包,并与与其“部分”相关的所有其他功能分组,或者完全是其他东西?
【问题讨论】:
标签: java jakarta-ee models
如果您正在对接口进行编程(对于任何合理大小/复杂性的系统来说总是一个好主意),那么通常效果很好的解决方案是拥有一个包含接口定义的项目/包,并合理地划分;例如:
com.mycompany.cms.domain.foocom.mycompany.cms.domain.barcom.mycompany.cms.domain.bar.usercom.mycompany.cms.domain.bar.page这套接口被系统中的所有层使用,并且希望实际的具体实现可以对层保持“私有”;例如在您的数据访问层中,您可能有:
package com.mycompany.cms.dataaccess.bar.user;
import com.mycompany.cms.domain.bar.user.CMSUser;
@Entity
@Table("CMS_USER")
public class CMSUserJPA implements CMSUser {
...
}
这是CMSUser 的一个实现,已经过适当的注释,可与 JPA 数据访问层一起使用。
很明显,您将在实施项目中对接口项目的包结构进行一定程度的“镜像” - 这使得正确地获得该结构非常重要 - 正如 Sean Patrick Floyd 在另一个答案中说,您必须找到一种既有意义又将每个包的文件数保持在可行范围内的分类法。
【讨论】:
我一般把包层分开:
例如,模型、业务和可视化。模型是数据支持,业务是我的程序的算法和显示屏幕。 您还可以在这些层内拥有对日志记录、异常处理的支持。
包的创建必须证明其类的相同上下文。例如,将处理数据库的类与数据视图的类放在同一个包中是有意义的。
希望对你有帮助
【讨论】:
对此没有绝对的规则。根据经验,我会说一个包应包含不超过 10 个且不少于 2 个编译单元,但口味不同。尝试找到一种分类法,使您可以将模型分成几个包,而不会感到不自然。
但我不会将模型放入与使用它们的代码相同的包中。尝试让你的包名代表其中发生的事情,例如
com.myapp.model.x
com.myapp.model.y
com.myapp.service.x
com.myapp.service.y
com.myapp.controller.x
com.myapp.controller.y
【讨论】: