Announcement Announcement Module
Collapse
No announcement yet.
Spring data, JPA entities, DAOs and design of my application Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

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

    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
    Last edited by balteo; Mar 7th, 2012, 04:10 AM.

  • #2
    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

    Comment


    • #3
      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:
      Code:
        @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.

      Originally posted by dr_pompeii View Post
      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

      Comment

      Working...
      X