Search code examples
javaspring-dataspring-data-jpaspring-data-mongodbspring-data-gemfire

Using same Entity classes in different spring data repositories

I'm trying to put together a project in which I have to persist some entity classes using different spring data repositories (gemfire, jpa, mongodb etc). As the data is more or less the same that needs to go into these repositories, I was wondering if I can use the same entity class for all of them to save me from converting from one object to another?

I got it working for gemfire and jpa but the entity class is already starting to looking a bit wired.

@Id // spring-data-gemfire
@javax.persistence.Id // jpa
@GeneratedValue
private Long id;

So far I can see following options:

  1. Create an interface based separate Entity (domain) classes - Trying to re-use same class looks like a bit of premature optimization.
  2. Externalize xml based mapping for JPA, not sure if gemfire and mongodb mapping can be externalized.
  3. Use different concrete entity classes and use some copy constructor/converter for the conversion.

Been literally hitting my head against the wall to find the best approach - Any response is much appreciated. Thanks

Solution

  • If by weird, you mean your application domain objects/entity classes are starting to accumulate many different, but separate (mapping) annotations (some semantically the same even, e.g. SD Common's o.s.data.annotation.Id and JPA's @javax.persistence.Id) for the different data stores in which those entities will be persisted, then I suppose that is understandable.

    The annotation pollution only increases too as the number of representations for your entities increases. For example, think Jackson annotations for JSON mapping or JAXB for XML, etc. Pretty soon, you have more meta-data then actual data, :-)

    However, it is more a matter of preference, convenience, simplicity, really.

    Some developers are purists and like to externalize everything. Others like to keep information (meta-data) close to the code using it. Even certain patterns have emerged to address these type of concerns... DTOs, Bounded Contexts (see Fowler's BoundedContext, which has a strong correlation to DDD and Microservices).

    Personally, I use the following rules when designing and applying architectural principals/decisions in my code, especially when introducing something new:

    1. Simplicity
    2. Consistency
    3. DRY
    4. Test
    5. Refactor

    (along with a few others as well... good OOD, SoC, SOLID, Design Patterns, etc).

    In that order too. If something starts getting too complex, refactor and simplify it. Be consistent in what you do by following/using patterns, conventions; familiarity is 1 key to consistency. But, don't keep repeating yourself either.

    At the end of the day, it is really about maintaining the application. Will someone else who picks up where you left off be able to understand the organization and logic quickly, and be able to maintain it... simplicity is king. It does not mean it is so simple it is not viable or valuable. Even complex things can be simple if organized properly. However, breaking things apart and introducing abstractions can have hidden costs (see closing thoughts).

    To more concretely answer (a few of) your questions...

    1. I am not certain about MongoDB, but (Spring Data) GemFire does not have an external mapping. Minimally, @Region (on the entity class) and @Id are required, along with @PersistenceConstructor if your entity class has more than 1 constructor. For example.

    2. This sounds sneakingly like to DTOs. Personally, I think BoundContexts are a better, more natural model of the application's data since the domain model should not be unduly tied to any persistent store or external representation (e.g. JSON, XML, etc). The application domain model is the 1 true state of the application and it should model the concept that is represents in a natural way, not superficially to satisfy some representation or persistent store (hence the mapping/conversion).

    Anyway, try not to beat yourself up too much. It is all about managing complexity. Try to let yourself just do and use testing and other feedback loops to find an answer that is right for your application. You'll know.

    Hope this helps.