Loading ...
Sorry, an error occurred while loading the content.

Re: To AOP or not to AOP that is the question.

Expand Messages
  • Andrew D
    Hi Dan, sounds like you had the same issue as myself when trying to figure out repositories etc. I found it started to make a bit more sense when using
    Message 1 of 9 , May 31, 2011
    View Source
    • 0 Attachment
      Hi Dan,

      sounds like you had the same issue as myself when trying to figure out repositories etc. I found it started to make a bit more sense when using aggregate roots instead of thinking of each object as a seperate entity in the domain model. Not sure if the customer-order example is the best one (guess it depends on if orders can live independently without a customer which I still have a hard time with, but then again you may want to process the order without a customer i guess) but it makes sense to me to have Customer.CreateNewOrder() which would add a new order to the orders collection of a customer.

      This way, it seems to almost give a purpose to things rather than simply having an order and a customer seperate which you populate and then persist with a repository which I found I was doing a great deal of when starting out down this path resulting in the anemic domain model you speak of.

      its slowly sinking in for me....



      --- In domaindrivendesign@yahoogroups.com, Dan Haywood <danhaywood@...> wrote:
      >
      > On 27/05/2011 14:57, Andrew D wrote:
      > >
      > > when you are developing, do you let the domain objects have access to
      > > the repositories ? like to know your thoughts
      > >
      >
      > I find it really hard to avoid anaemic domain objects without allowing
      > them access to the repositories, either for update or even just for
      > simple retrieval (walking the object graph).
      >
      > A subsidiary question is *how* to provide domain objects with access. I
      > prefer dependency injection, but a thread-local service locator
      > singleton also works (but can be harder to test). I don't like
      > providing the repository in the method call as a parameter because I
      > consider that it leaks implementation details to the caller.
      >
      > An AOP style can be useful to wrap domain objects when instantiated so
      > that the introduced aspect can know when the wrapped domain objects is
      > dirty and therefore flush/commit the object at the end of the
      > transaction. Of course, this is what frameworks such as
      > (N)Hibernate/JPA/EF do automatically, so there's not necessarily any
      > need to reinvent that particular wheel.
      >
      > HTH
      > Dan
      >
      > blog: http://danhaywood.com
      > open source: http://incubator.apache.org/isis
      > book: http://pragprog.com/titles/dhnako
      >
    • silenus99
      If you use dependency injection, aren t you introducing infrastructure to your domain model?
      Message 2 of 9 , Jun 10, 2011
      View Source
      • 0 Attachment
        If you use dependency injection, aren't you introducing infrastructure to your domain model?

        --- In domaindrivendesign@yahoogroups.com, "Andrew D" <andrewdeakins@...> wrote:
        >
        > Hi Dan,
        >
        > sounds like you had the same issue as myself when trying to figure out repositories etc. I found it started to make a bit more sense when using aggregate roots instead of thinking of each object as a seperate entity in the domain model. Not sure if the customer-order example is the best one (guess it depends on if orders can live independently without a customer which I still have a hard time with, but then again you may want to process the order without a customer i guess) but it makes sense to me to have Customer.CreateNewOrder() which would add a new order to the orders collection of a customer.
        >
        > This way, it seems to almost give a purpose to things rather than simply having an order and a customer seperate which you populate and then persist with a repository which I found I was doing a great deal of when starting out down this path resulting in the anemic domain model you speak of.
        >
        > its slowly sinking in for me....
        >
        >
        >
        > --- In domaindrivendesign@yahoogroups.com, Dan Haywood <danhaywood@> wrote:
        > >
        > > On 27/05/2011 14:57, Andrew D wrote:
        > > >
        > > > when you are developing, do you let the domain objects have access to
        > > > the repositories ? like to know your thoughts
        > > >
        > >
        > > I find it really hard to avoid anaemic domain objects without allowing
        > > them access to the repositories, either for update or even just for
        > > simple retrieval (walking the object graph).
        > >
        > > A subsidiary question is *how* to provide domain objects with access. I
        > > prefer dependency injection, but a thread-local service locator
        > > singleton also works (but can be harder to test). I don't like
        > > providing the repository in the method call as a parameter because I
        > > consider that it leaks implementation details to the caller.
        > >
        > > An AOP style can be useful to wrap domain objects when instantiated so
        > > that the introduced aspect can know when the wrapped domain objects is
        > > dirty and therefore flush/commit the object at the end of the
        > > transaction. Of course, this is what frameworks such as
        > > (N)Hibernate/JPA/EF do automatically, so there's not necessarily any
        > > need to reinvent that particular wheel.
        > >
        > > HTH
        > > Dan
        > >
        > > blog: http://danhaywood.com
        > > open source: http://incubator.apache.org/isis
        > > book: http://pragprog.com/titles/dhnako
        > >
        >
      • Dan Haywood
        ... No. Infrastructure is needed to perform the dependency injection into the domain objects, but it isn t the domain objects that are doing the dependency
        Message 3 of 9 , Jun 11, 2011
        View Source
        • 0 Attachment
          On 11/06/2011 03:48, silenus99 wrote:

          If you use dependency injection, aren't you introducing infrastructure to your domain model?

          No.  Infrastructure is needed to perform the dependency injection into the domain objects, but it isn't the domain objects that are doing the dependency injection.

          Dan

        Your message has been successfully submitted and would be delivered to recipients shortly.