Announcement Announcement Module
No announcement yet.
Structure of domain classes Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Structure of domain classes


    I am new to Spring, in particular Spring Data Neo4j, and despite some problems getting everything running I am very excited about what I see.

    I have a question on code structure, that stems from me having absolutely no idea what is going on under the hood (and also from lack of experience). From all the examples I have seen, the domain have consisted of simple classes without any hierachy (apart from java.lang.Object, of course).

    From what I have learned about software architecture, you should implement some interface in order to decouple your implementation. Also, I feel an urge to factor out whatever I can, and therefore thought I would make a class such as

    abstract class GraphEntity {
      private Long nodeId;
      public boolean equals(Object o) {
        return o == this ||
          o != null
          && getClass() == o.getClass()
          && nodeId.equals(((GraphEntity) o).nodeId);
      public int hashCode() {
        return nodeId != null ? nodeId.hashCode() : super.hashCode();
    This way I implement these two important methods once and for all, and at the same time encapsulate the node id.

    All domain classes backed by a node or relationship would then inherit from this, and at the same time implement the respective domain interface, e.g.

    public class MovieNode extends GraphEntity implements Movie {
    I would put the interfaces in one package ([app].domain), and GraphEntity and the implementations in another one ([app].domain.impl)

    What do you think? Pros/cons/better ways? Problems with the mapping system? Any thoughts are appreciated.

    Regards, Michael.

  • #2
    This is sort of how I expected to structure my classes but after looking at the cineasts example it looks like they implemented it slightly different. Also interested in input.


    • #3
      Sounds good, cineasts is not focused on factoring everying out but on a simplistic approach that should be easier to follow.

      You could even put the @NodeEntity annotation on you GraphEntity class.


      • #4
        Thanks for your input. If you put @NodeEntity on GraphEntity and find that you want a relationship entity, will the @RelationshipEntity annotation on the extending class then override @NodeEntity?


        • #5
          That is a good question. I think they will just clash and create an indeterministic scenario.

          What is it you want to achieve?


          • #6
            I wanted to use GraphEntity as the base for both node- and relationship wrappers. So I guess I should annotate the extending classes instead of GraphEntity?


            • #7
              Yep, I think that is safest and also semantically more correct.

              You can always choose to mix-in interfaces with the correct annotation which should also work.