具有接口的Spring目录结构（最佳实践）_java

我目前正在编写我的第一个Spring应用程序（Spring Boot + Hibernate）。 我在检查了其文档中的最佳做法目录结构。 这说得通。

问题1：

我有一些子类扩展的interface （或Abstract class ），所以对于父类，我只需要一个@Repository 。 我已经决定这样做：

com
 +- example
     +- myapplication
         +- Application.java
         |
         +- message
         |   +- AbstractMessage.java
         |   +- IMessageRepository.java
         |   +- MessageRepositoryImpl.java
                +- messageTypeA
                |  +- messageTypeA.java
                |  +- messageTypeAService.java
                +- messageTypeB
                |  +- messageTypeB.java
                |  +- messageTypeBService.java

问题2：

现在，我有一个要保存的新entity ，称为Group 。 所以我可以做的是在与Message相同的级别上添加一个Group目录。 但是，该Group实际上是Message的一部分（例如，在逻辑上），因此，如果它是同一message目录的一部分，则实际上是有意义的（ 我们将它们另存为不同实体的唯一原因是，派生更有意义这样进行分析 ）。 此外，我什至使用相同的MessageRepository保存它（我只是在界面中添加了第二种方法，如下所示：）

public interface MessageRepository {

    void insert(AbstractMessage message);

    void insert(AbstractMessage message, AbstractGroup group);
}

像下面这样的东西会好吗？ 还是每个 entity都应该有自己的包装？ 我在想这个吗？

com
 +- example
     +- myapplication
         +- Application.java
         |
         +- message
         |   +- AbstractMessage.java
         |   +- IMessageRepository.java
         |   +- MessageRepositoryImpl.java
             |  +- messageTypeA
             |     +- messageTypeA.java
             |     +- messageTypeAService.java
             |  +- messageTypeB
             |     +- messageTypeB.java
             |     +- messageTypeBService.java
             |
             +- group
                +- AbstractGroup.java
                +- GroupTypeX.java // same service as message, just different entity
                +- GroupTypeY.java // same service as message, just different entity

这更多是基于观点的，但是我想给您一些建议。

首先，命名。
接口上的I前缀是IBM识别它们的“古老”技术。 拜托，不要那样做，它是多余的，在新鲜的环境中没有意义。 什么是I-MessageRepository ？
您会在Eclipse RCP项目或IBM的任何产品上找到这种命名约定。

然后执行名称。 不要使用Impl后缀，它不会对正在阅读或编辑您的代码的人说什么。
给它起一个名字，说明它的用途或领域范围。

ActiveMQMessageRepository
FileMessageRepository
TcpMessageRepository

第二， Repositories 。
存储库应管理一种类型的对象，但不能超过一种。 使用Services来协调多个Repositories 。 这将使每个人都更容易调试，并且将使许多代码分离。

第三， packages 。
尝试始终保持扁平的包装结构。 扁平结构更易于维护，更易于观察，更易于理解。 不要创建数十个子包，例如

- messages
   - services
       MessageService
     - implementations
        ...
   - repositories
       MessageRepository
     - abstract
         AbstractMessageRepository
     - implementations
         TextMessageRepository
   - exceptions
     - runtime
     - checked
         UnsupportedMessageException

可怕而无用。 而且您无法利用软件包的可见性 。

因此，请将messages和groups保留在单独的程序包中，并为其提供自己的Repository 。

从包公开接口，而不是具体实现。 （若有可能）

我同意上面的@LppEdd答案。 只是一个问题，你说的是什么意思

（我们将它们另存为不同实体的唯一原因是，以这种方式导出分析更有意义）。

具有接口的Spring目录结构（最佳实践）

问题描述

1楼

2楼