Results 1 to 2 of 2

Thread: Injecting business objects into other business objects ?

  1. #1

    Default Injecting business objects into other business objects ?

    Hello

    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. #2
    Join Date
    Feb 2005
    Location
    Boston, MA
    Posts
    1,142

    Default

    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:

    Code:
    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;
        cb.callback1(someargument);
        // more daoB stuff
      }
    
    public class someService {
      setDaoA(daoA a) { ... }
      setDaoB(daoB b) { ... }
      doSomeService() {
        b.methodB1(a);
      }
    }
    Basically I'm using a callback to do the method injection you are looking for.

Similar Threads

  1. Spring-based architectural approach
    By diegum in forum Architecture
    Replies: 9
    Last Post: May 10th, 2007, 04:09 PM
  2. Replies: 2
    Last Post: Oct 10th, 2005, 05:12 PM
  3. Testing Business Objects
    By jopaki in forum Container
    Replies: 2
    Last Post: Aug 16th, 2005, 04:11 AM
  4. Binding to business domain objects
    By klr8 in forum Architecture
    Replies: 2
    Last Post: Mar 15th, 2005, 01:21 AM
  5. Should Business Objects have References to DAOs?
    By sethladd in forum Architecture
    Replies: 9
    Last Post: Aug 25th, 2004, 01:18 PM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •