Any negative experience?

[manifoldronin]

Yes.. but it a hell of a lot easier on the eyes.

I can see in a single blink what is going on.. I need more blinks to see what is going on in the xml based version.... just because there is more (verbose) text to read.. not because the semantics are simpeler. Does this have to be so difficult to understand? I`m not a computer.. I can only process a few words a second.

I understand your point, which is applicable to almost any debate on XML vs. proprietary domain languages. I don't know if I want to get into one at this time, though.

[Alarmnummer]

I understand your point, which is applicable to almost any debate on XML vs. proprietary domain languages. I don't know if I want to get into one at this time, though.

In most cases I don`t care very much because I don`t spend a lot of time in it. But I spend a lot of time in Spring, and glue together very complex systems (and I`m loving it) but sometimes I have trouble to see what larger beans do and that has to do with the verbose syntax. I can`t see it with a single look.

[Ben Alex]

We are in agreement here. Our primary point of disagreement is whether domain objects should ever be allowed to access application services, not just other domain collaborators.

This is over a year old, so let me know if your view has changed, but in http://forum.springframework.org/showthread.php?t=9846 you state your position pretty clearly:

But it seems easier to me to just stick with what Spring makes easy... If you need a singleton collaborator... it's probably application logic. [and doesn't belong in a domain object]

I still have the same view. I am not a big fan of domain objects that have injected singletons to perform application logic. But it's not a big religious issue to me, just that of personal preference and what I've found works. As that thread you mentioned dealt with, Spring does make it possible to dependency inject collaborators into your domain objects. I did do this myself on one project, but shifted away from it in favour of the domain subproject.

Some simple examples. When an operation is performed on a domain object that will trigger a change in workflow state, I like for my domain object to directly message my OSWorkflow service to effect the change. When a delete operation needs to be performed on a single domain object, I like the domain object to be issued the delete operation, and allow him to in turn pass the message onto the DAO.

In that case I'd have my FooManager.delete(Foo) method handle the delete, which is also convenient because FooManager will be called within a broader transaction that might be performing other mutations.

I am not saying there is one right answer here. As you have mentioned, the approach you have taken has worked for you on successful projects. But right now, Spring only supports your approach, not mine.

I think you could use the DI into DOs if you wanted to. And as you are aware, this will continue to improve as AspectJ et al capabilities become richer.

I agree different approaches will suit different people and different projects. Awareness of the pros and cons of both makes people more capable developers and should be encouraged.

[hucmuc]

We are in agreement here. Our primary point of disagreement is whether domain objects should ever be allowed to access application services, not just other domain collaborators.

This is over a year old, so let me know if your view has changed, but in http://forum.springframework.org/showthread.php?t=9846 you state your position pretty clearly:

But it seems easier to me to just stick with what Spring makes easy... If you need a singleton collaborator... it's probably application logic. [and doesn't belong in a domain object]

I still have the same view. I am not a big fan of domain objects that have injected singletons to perform application logic. But it's not a big religious issue to me, just that of personal preference and what I've found works. As that thread you mentioned dealt with, Spring does make it possible to dependency inject collaborators into your domain objects. I did do this myself on one project, but shifted away from it in favour of the domain subproject.

Some simple examples. When an operation is performed on a domain object that will trigger a change in workflow state, I like for my domain object to directly message my OSWorkflow service to effect the change. When a delete operation needs to be performed on a single domain object, I like the domain object to be issued the delete operation, and allow him to in turn pass the message onto the DAO.

In that case I'd have my FooManager.delete(Foo) method handle the delete, which is also convenient because FooManager will be called within a broader transaction that might be performing other mutations.

I am not saying there is one right answer here. As you have mentioned, the approach you have taken has worked for you on successful projects. But right now, Spring only supports your approach, not mine.

I think you could use the DI into DOs if you wanted to. And as you are aware, this will continue to improve as AspectJ et al capabilities become richer.

I agree different approaches will suit different people and different projects. Awareness of the pros and cons of both makes people more capable developers and should be encouraged.

The problem with all this disussion is that it avoids the topic of stateful objects. Ben, the scenerios that you have come up with makes sense to me too. But, as I said in my previous posts I sometimes need stateful objects to have true polymorphic behaviour. However, I twist my design to use singletons and pass data via arguments because, quite frankly, Spring comes up with weird and non-intuitive approaches for creating prototype objects on the fly. Hopefully, this aspectj stuff provides an intuitive AND explainable approach.


Dino