Structure of domain classes

[halleknast]

Hi.

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 {
  @GraphId
  private Long nodeId;

  @Override
  public boolean equals(Object o) {
    return o == this ||
      o != null
      && getClass() == o.getClass()
      && nodeId.equals(((GraphEntity) o).nodeId);
    }

  @Override
  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.

@NodeEntity
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.

[Jackal789]

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.

[MichaelHunger]

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.

[halleknast]

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?

[MichaelHunger]

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

What is it you want to achieve?

[halleknast]

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?

[MichaelHunger]

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.

Michael