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

Question

我目前正在编写我的第一个 Spring 应用程序（Spring boot + hibernate）。我在这里查看了他们文档中的最佳实践目录结构。这说得通。问题一：我有一个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。所以我能做的就是添加一个Group与Message. 然而，这Group实际上是（就像逻辑上的）的一部分，所以如果它是同一个目录的Message一部分实际上是有意义的（我们将它们保存为不同实体的唯一原因是因为以这种方式派生分析更有意义）。此外，我什至使用相同的方法来保存它（我只是在界面中添加了第二种方法，如下所示：）messageMessageRepositorypublic 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

Answer 1

这更多是基于意见的事情，但我想给你一些建议。

首先，命名。

接口上的I前缀是 IBM 用来识别它们的“古老”技术。请不要那样做，这是多余的，在新鲜的环境中没有意义。什么是I-MessageRepository？！您会在项目或 IBM 的任何产品

中发现这种命名约定。Eclipse RCP

然后是实现名称。不要使用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.

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

Answer 2

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

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