Announcement Announcement Module
No announcement yet.
Injecting business objects into other business objects ? Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Injecting business objects into other business objects ?


    I'm having troubles applying my domain model design choices into Spring architecture, and I'm hoping one might give me enlightening ideas

    In almost every Spring sample application I've seen, I usually see one or several Services (call this Facades or BO), each one of them using injected DAOs to perform the real business job. This is fair, and working fine, however I would like my application to have some kind of "super service", acting as a delegator to several other classic services, each one of these classic services then being injected with DAOs. On top of that, I also need my DAOs to be able to lookup each other's methods.

    A straightforward example would be :

    I have a fooService using aDao and bDao, and in my bDao implementation, I need to lookup aDao methods, because the bDao business process is being altered based on data being accessible through the aDao. Then I need a superFooService, being able to control this fooService, but also barService, xxxService, and so on.

    Is this a Bad (tm) architectural practice, and if not can I still wire Services together via Spring ? I smell that in order to make DAOs talk to each other, I may need to use their parent service as a communication bridge between them, but this sounds like the DAOs would need to lookup their parent to see the "outside world", and I can't figure out if this is regarded, too, as a bad practice.

    Is the "one service to bind them all" practice recommended, and if it is, how am I supposed to have the underlying DAOs know about each other ?

    Thanks for any input

  • #2
    One thing to ask yourself would be: how would you unit test this?

    Having dependencies like you mention sounds like it would make it difficult to do so. Although unit testing isn't the only consideration when creating an architecture. Spring tends to strive for statically defined simple dependency relationships between its objects, partially to improve testability.

    However your problem is solvable:

    interface daoCallbackB {
      public void callback1(Object someargument);
    interface daoB {
      public void methodB1(daoCallbackB cb);
    interface daoA {
      public void method1();
      public void method2();
    public class daoAImpl implements daoCallbackB, daoA {
      public void method1() { do stuff; }
      public void method2() { do stuff; }
      public void callback1(Object someargument) { 
        do stuff on someargument; 
    public class daoBImpl implements daoB {
      public void methodB1(daoCallbackB cb) {
        // daoB stuff
        Object someargument;
        // more daoB stuff
    public class someService {
      setDaoA(daoA a) { ... }
      setDaoB(daoB b) { ... }
      doSomeService() {
    Basically I'm using a callback to do the method injection you are looking for.