Announcement Announcement Module
Collapse
No announcement yet.
Where should I add custom Entity methods? Best Practice? Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Where should I add custom Entity methods? Best Practice?

    Lets say I want to write my own entity method for a Roo managed class that is similar to what is usually found in
    *_Roo_Entity.aj

    Lets assume the method is an update method and not a finder.
    Should I write that method in a new Aspect: MyDomainObject_Entity.aj
    or should put that method in MyDomainObject class directly?

    It seems making another Aspect to put the entity methods in is right way as far as separation of concerns goes.

    What do other people do?

    ---EDIT---
    I ended up putting the methods in the domain object directly and marking the methods @Transactional as it seemed appropriate this time.
    I guess if need more complexity I should make a service and mark the service @Transactional.

    Similar thread see:
    http://forum.springsource.org/showthread.php?t=86561
    Last edited by agentgt; Sep 2nd, 2010, 02:26 PM.

  • #2
    IMHO, the only reason to put anything in an aspect is if you want to apply it to more than one class of entity. But if it's a finder that's specific to one entity type, just put it directly into the Java class for that entity.

    Comment


    • #3
      I think I somewhat agree

      I agree that aspects are generally used for multiple classes but its clear the Spring ROO project has used them for something that Java lacks: Partial Classes (see http://en.wikipedia.org/wiki/Partial_class).

      Thus its a separation of concern issue (same entity different problem) not a cross-cutting concern (multiple entities same problem). Luckily AspectJ can handle both.

      My issue like many Java developers is that I want to separate behavior from data because of the annoying DAO pattern that we are so familiar with. I feel making an aspect like ROO is doing would be a happy middle ground between old enterprise-java-semi-functional-soa and new agile-ruby-domain-driven-oop style.

      Originally posted by andrews View Post
      IMHO, the only reason to put anything in an aspect is if you want to apply it to more than one class of entity. But if it's a finder that's specific to one entity type, just put it directly into the Java class for that entity.

      Comment


      • #4
        Originally posted by agentgt View Post
        I agree that aspects are generally used for multiple classes but its clear the Spring ROO project has used them for something that Java lacks: Partial Classes
        My understanding is that Roo uses aspects (specifically ITDs) simply as an expedient to facilitate round-tripping, by keeping the developer-maintained code separate from the Roo-maintained code. It's more "separation of authorship" than "separation of concerns".

        Originally posted by agentgt View Post
        I want to separate behavior from data because of the annoying DAO pattern that we are so familiar with.
        Roo aims to keep them together to avoid the annoying anaemic domain model problem that we are also familiar with. But now we're starting to stray into religion rather than technology.

        Comment

        Working...
        X