Spring data, JPA entities, DAOs and design of my application

[balteo]

Hello,

I currently have a hierarchy of JPA entities that relies on inheritance as follows:
-an Account abstract base class
-a ChildminderAccount subclass that extends Account
-a ParentAccount subclass that also extends Account
-an Advertisement abstract base class
-a ChildminderAdvertisement subclass that extends Advertisement
-a ParentToChildminderAdvertisement subclass that extends Advertisement
-a ParentToParentAdvertisement subclass that extends Advertisement
and so on

As one can see this implies quite a number of JPA entities. Because my DAOs are parameterized using the JPA entities, I currently have too many DAOs and I feel my design is flawed somewhere.

For instance in my AdvertisementService class, I have 4 AdvertisementDAOs.

Can anyone please advise a better design?

Regards,

J.

EDIT: My DAO intefaces extend Spring's CrudRepository interface

[dr_pompeii]

Hello

As one can see this implies quite a number of JPA entities. Because my DAOs are parameterized using the JPA entities, I currently have too many DAOs and I feel my design is flawed somewhere.

Is normal that Each Entity should has its own DAO class to handle the persistence or CRUD operations.

Could be nice only has the AdvertisementDAO class to work with ChildminderAdvertisement, ParentToChildminderAdvertisement, ParentToParentAdvertisement. Same case for Account. The problem is that if for each entity has a lot of CRUD operations (making the class verbose), and you must discriminate what subclass you want to manipulate.

For instance in my AdvertisementService class, I have 4 AdvertisementDAOs.

Why 4? If you only has three concrete classes ChildminderAdvertisement, ParentToChildminderAdvertisement, ParentToParentAdvertisement. Advertisement is an abstract class

Can anyone please advise a better design?

Is relative, you have here the dilemma about low coupling and high cohesion

[balteo]

Hello Manuel!

I decided to have a DAO for the abstract Entity so that I can perform operations common to all entities such as for instance something like this:

  @Modifying
  @Transactional
  @Query("UPDATE Advertisement a SET a.advertisementActivated = false WHERE a.account.accountID = ?1")
  def deactivateAdvertisementsFromAccountID(accountID: Integer): Int

So that adds up to a total of 7 DAOs just to deal with the concepts of Advertisements and Accounts...

Regarding the first part of your reply, are you basically saying that it is OK to have that many DAOs?

I am not sure I understand what you said about low coupling and high cohesion. On which side is my current design tipped?

Regards,

Julien.

Hello
Is normal that Each Entity should has its own DAO class to handle the persistence or CRUD operations.

Could be nice only has the AdvertisementDAO class to work with ChildminderAdvertisement, ParentToChildminderAdvertisement, ParentToParentAdvertisement. Same case for Account. The problem is that if for each entity has a lot of CRUD operations (making the class verbose), and you must discriminate what subclass you want to manipulate.


Why 4? If you only has three concrete classes ChildminderAdvertisement, ParentToChildminderAdvertisement, ParentToParentAdvertisement. Advertisement is an abstract class


Is relative, you have here the dilemma about low coupling and high cohesion