インターフェイスを持つ春のディレクトリ構造（ベストプラクティス）

Tiberiu

私は現在、私の最初のSpringアプリケーション（春ブーツ+休止）を書いています。私は彼らのドキュメント上のベストプラクティスのディレクトリ構造を確認し、ここで。それは理にかなっている。

質問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。それでは、私は何ができることは追加であるGroupと同じレベルにディレクトリをMessage。しかし、これはGroup実際の一部でありMessage、それは同じの一部であった場合、それは実際に理にかなっているので、（論理的に、のような）messageディレクトリ（道ということ、それが由来分析により理にかなっているので、我々は別のエンティティとして保存されている唯一の理由は、）。さらに、私も同じを使用していますMessageRepository、私はちょうどそのようなインターフェイスで第二の方法を追加しました（それを保存するために:)

public interface MessageRepository {

    void insert(AbstractMessage message);

    void insert(AbstractMessage message, AbstractGroup group);
}

以下BEいいたい何か？または必要があるすべての entity独自のパッケージを持っていますか？私はこれをoverthinkingだろうか？

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

LppEdd：

それは、より多くの意見に基づくものだが、私はあなたのカップルの提案を与えるしたいと思います。

まず第一に、命名。インターフェイス上のプレフィックスはそれらを認識するためにIBMから「古代の」技術です。、その、それのreduntantをしないでください、それは新鮮な環境の中で意味がありません。何？！あなたは上のほとんどの命名規則のこの種見つけるプロジェクト、またはIBMによって任意の製品を。
II-MessageRepository
Eclipse RCP

そして、実装名。使用しないでくださいImpl、それはあなたのコードを読んだり編集している人には何も言っていない、接尾辞を。
それにその目的やドメインのスコープとは何かと言う名前を付けます。

ActiveMQMessageRepository
FileMessageRepository
TcpMessageRepository

第二に、Repositories。
リポジトリは、1個以下の、オブジェクトの単一のタイプを管理する必要があります。使用Services複数を調整しますRepositories。これは、デバッグに皆のためにそれが容易になり、それは多くのコードを分離します。

第三に、packages。
常にフラットパッケージ構造を持つようにしてください。フラットな構造が容易に理解するために、見て簡単に、保守が容易です。以下のようなサブパッケージの数十を作成しないでください

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

恐ろしいと役に立ちません。そして、あなたは、パッケージの可視性を活用することはできません。

だから、続けるmessagesとgroups別々のパッケージに、そしてそれらに彼ら自身を与えますRepository。

パッケージではなく、具体的な実装からインタフェースを公開します。（可能であれば）

インターフェイスを持つ春のディレクトリ構造（ベストプラクティス）

おすすめ