none
Dependency injection for wiring building block components to create applicaion RRS feed

  • Question

  •  

    Need some help in finding if Dependency injection (unity) is suitable in my scenario.

    Can i use unity for wiring my basic components to form an application. with each component not having a explicit dependency(no dependenc injection) on other component

    i am working on a framework for testing web applications. there are some basic components like data generator/source (which holds data to send to web app), requestor (which actually make web request), assert(components which do assert for response) and reporting(generate reports).

    the data flow is more like a pipeline (in which one type of component works only after outut from previous component). Like data generators sends data ---> Requestor --->assert ---->Report. So Assert doesn't work unless Requestor has finished its job.

    Although they are pipeline, but i don't think them as dependency. for ex Requestor class doesn't have any direct/explicit dependency on Assert. Requestor job is only to send request. and when repsone is recevied it sould have some event pub-sub mechanism so that Assert can start there job.

    each component can have mulitple instance. example Requestor can have multiple type of Asserts associated with it.

    My requirement is to create tests for mulitple web applications using these basic building blocks(componet). SO there is need to add/remove components from config. Like replacing the reporting component to have a new type of reporting. and changing reproting component doesn't effect any other part.


    Regards
    Tuesday, April 8, 2008 6:39 PM

Answers

  • It seems more like a messaging system that you're describing there.

     

    The only information shared across pipeline components would be the message that gets gradually populated as it passes through the system.  You would then need some sort of mechanism, such as a pipline component that would understand somehow to instantiate each component, and I would suggest a provider "pattern" for that.  If you need to know what patterns are used, it's a strategy and factory pattern is reality.

     

    You would typically only use dependency injection if one component was dependency directly upon another, then you could inject that dependency into the object, using the interface the dependency implements.  One good use for the dependency injection, one that I suspect you might have read about is using object mocking to inject as dependencies for testing.  From what you're saying so far, it seems like you don't need to use dependency injection.

    From the point of view of proceeding forward, if you find yourself creating an object within any of those pipeline components, that would be what you would typically use dependency injection for, so for example, one of the components uses a database interface that you wanted to supply implementation for.

     

    What you describe in the final part of your post is effectively a factory, such as a reporting factory, and if the implementation changes, then a provider type model or "pattern" is appropriate for this.

     

    I hope this helps,

     

    Martin Platt.

     

    Tuesday, April 8, 2008 10:37 PM