locked
Practical real world implementation of Dependency Injection RRS feed

  • Question

  •  

    i was trying P&P Unity application block and was thinking, who much functionality a generic container like Unity can provide in solving real world loosely coupled systems? My feeling is most of the time you will end up wirting your own container over Unity.

     

    The basic functionality of container is to maintain mapping between INterface and concreated class and inject concreate class based on attribute applied.

     

    Unity supports container from config file, but the schema is too simple (and terminology used like <containers> doesn't fit into real world scenario) and only supports direct mapping. In my particular case i need functionality like CAB (workItem/context/modules) Unlike CAB this will be a class library instead of GUI App(no smartparts/view)

     

    A Xml node like <container> might not make much sense to the user of my framework. Users will prefer to have names which they can relate to the application they are developing.

     

    So probably I would end up writing my own custom config sections/configreaders, which will read value from config and will then configure the container.

    Monday, April 14, 2008 7:16 PM

Answers

  •  

    Hello,

    I have used Spring.Net it one of my real life projects and think its useful for the following reasons-

    1. Simple implementation of DI. So, you can think of unit testing at ease.

    2. It also gives you simple means to create your singleton objects.

    3. An advantage over your custom container is, you don't need to write a lot of codes for it.

     

    If you think, your users are better with custom config sections, you may wish to create your own containers. But other than the xml configuration file, do you have any other reason for not using these DI containers? I guess, if only the xml formatting is an issue, you can still use the DI containers with your custom configuration file and internally rely on the ready to hit products like Unity/Spring.Net to create your objects programmatically with some sort of a wrapper.

     

    Hope it helps you decide.

     

    -Sohan

    http://smsohan.blogspot.com

     

    ---------------------------------------

    Mark as Answered if it was really helpful to you.

    Tuesday, April 15, 2008 9:55 AM
  • Hi

     

    Unity is but one example of a DI container, there are loads of others, windsor, spring and so on.

    To me a IOC/DI is very useful, just because it provides

    - a central api to get "services" from (this opens some AOP possibilites)

    - a configurable way to inidicate what implementation of a certain contract you get

    - a configurable way to indicate reuse/creation of new objects

     

    imho, DI and dynamic factory are quite similar, DI only provides you with some auto wire up functionality which otherwise you'd have to write yourself..

     

    basically, the fact that you write ServiceFactory (or Container).Create<T> and you get back the required implementation is a very useful api choice for most projects (see the points above).

    Wednesday, April 16, 2008 9:46 AM

All replies

  • Take a look at:

     

    http://martinfowler.com/articles/injection.html

     

    It won't tell you about the unity framework, but is a good resource for dependency injection if that helps your research at all.

     

    Personally I use DI for mock testing, but I haven't used the unity framework personally.  If you would like to discuss that and have particular questions, I'm happy to help,

     

    Good luck,

     

    Martin Platt.

     

    Monday, April 14, 2008 10:45 PM
  • I have gone through that article (and lot of others). DI is definately good, but i was just thinking how useful "Out of the box containers" are in  developing Real world component based application development, with components being almost decoupled with each other.

     

    Say for example the terminology these container uses to configure them. As mentioned earlier Eventhough Unity has a <continer> tag within which you can specify types to load, but still I can't use that unity config seciton "as it is",, as users of my framework can't relate to the word "container".

     

    DI containers are useful in having implementation of Constructor/Setter/Method injection. But for configuring these containers you need to write up a lot of code(which reads your config section and configures continer)

     

    Regards,

     

    Tuesday, April 15, 2008 4:47 AM


  • As I said, I haven't used the container.

    I knew of their existance, but didn't really see the need to do anything special for DI at all, configuration driven containers seemed a little like overkill to me personally.  I've always managed withouth them, however I may be missing something great, I have to admit.

    My thoughts are simply that I have not come across a reason to use a framework for DI, so I haven't gone in search of one.  I think we have to approach that choice on a case by case basis, if it feels too difficult then it possibly is, look for a different approach....

    I'm sorry that I couldn't add any value to your post by answering specifically.


    Martin Platt.
    Tuesday, April 15, 2008 5:08 AM
  • I'm interesting in hearing why you've selected DI over, say, a factory pattern? I admit that this is a leading question but I don't want to...lead the witness.

    Tuesday, April 15, 2008 6:18 AM


  • For me, a factory pattern is for similar implementations of a fixed interface (or abstract class)  DI can also allow that functionality, but personally, I use it for mocking with unit testing, in which case it would appear to be a good fit with a factory pattern?

    I've also had the situation happen where I have designed something and that implementation has change mid-way through development, and have been able to easily inject a new object.

    Yes, we could easily have gotten around that one with a provider type setup, but still wouldn't help the mocking and unit testing approach. 

    Well, that's why I used it anyway.

    Martin Platt.
    Tuesday, April 15, 2008 6:22 AM
  • It's interesting that a number of people use DI because of unit testing, it certainly seems to cause a number of debates. Personally I don't like having to alter my model to allow for the injection so I use a broker (although that does require some 'late binding' so I wouldn't sell it as an ideal solution) and TypeMock for my tests.

     

    Tuesday, April 15, 2008 8:39 AM
  •  

    Hello,

    I have used Spring.Net it one of my real life projects and think its useful for the following reasons-

    1. Simple implementation of DI. So, you can think of unit testing at ease.

    2. It also gives you simple means to create your singleton objects.

    3. An advantage over your custom container is, you don't need to write a lot of codes for it.

     

    If you think, your users are better with custom config sections, you may wish to create your own containers. But other than the xml configuration file, do you have any other reason for not using these DI containers? I guess, if only the xml formatting is an issue, you can still use the DI containers with your custom configuration file and internally rely on the ready to hit products like Unity/Spring.Net to create your objects programmatically with some sort of a wrapper.

     

    Hope it helps you decide.

     

    -Sohan

    http://smsohan.blogspot.com

     

    ---------------------------------------

    Mark as Answered if it was really helpful to you.

    Tuesday, April 15, 2008 9:55 AM
  • Thanks to all for your comments

     

    1. DI might be an overkill in the app i am working (Provider might have been a better solution). But my idea of primarly thinking of DI was to get a hands on of a DI based application(large enough then a "Hello World" app and samller enough to handle complexities easily).

     

    2. App is supposed to get a lot of customization/changes from end users. So my idea was to see how easily a DI based decoupled app can handle changes. Decoupled/Component wiring/EventBroker/Container provided cross-cutting concerns, how well they  fit into real world.

     

    3. When i started with Unity Container, i felt a signifcant amount of coding effort is to be done by the App. My idea of "starting the Thread" was to see how others are developing DI based apps and how much effort it takes for that.

     

     

     

    Tuesday, April 15, 2008 12:23 PM


  • Ah okay.


    I recently used DI in a fairly large messaging system with good results.

    I didn't use a framework for it, but wrote my own base classes to specifically address the problem space, so a lot of the pain was taken away from that approach.

    Loosely coupled systems only cater for small non-interface breaking changes, but with those sort of changes, changes in implementation, DI is very effective.

    I didn't find the process of using DI a difficult or particularly time consuming process.  Takes a lot more time to mock up objects that it does to do the DI part.

    Personally I like DI and will continue to use it as a custom implementation, until I find a reason not to do so, such as it becoming too dificult.

    Good luck,

    Martin Platt.
    Tuesday, April 15, 2008 11:19 PM
  • Hi

     

    Unity is but one example of a DI container, there are loads of others, windsor, spring and so on.

    To me a IOC/DI is very useful, just because it provides

    - a central api to get "services" from (this opens some AOP possibilites)

    - a configurable way to inidicate what implementation of a certain contract you get

    - a configurable way to indicate reuse/creation of new objects

     

    imho, DI and dynamic factory are quite similar, DI only provides you with some auto wire up functionality which otherwise you'd have to write yourself..

     

    basically, the fact that you write ServiceFactory (or Container).Create<T> and you get back the required implementation is a very useful api choice for most projects (see the points above).

    Wednesday, April 16, 2008 9:46 AM
  •  frederikm wrote:

    imho, DI and dynamic factory are quite similar, DI only provides you with some auto wire up functionality which otherwise you'd have to write yourself..

    I agree, which is why I prefer the factory route because, typically, DI requires you passing in constructor information into the domain modelled objects and that gets on my puriest nerves...reason enough for me not to use it! (I must confess I've not tried Spring and I'm interested in doing so now).

     

     

     

    Wednesday, April 16, 2008 1:04 PM
  • true,

    Ideally your objects should be container agnostic, or even better formulated: container unaware.

    however, as you're injecting dependencies you have to know (more or less) which properties or constructors to inject..

    technical limitations ^^

    but hey i use NHibernate.Mappings.Attributes as well so Stick out tongue

     

    Wednesday, April 16, 2008 2:20 PM
  • Next you'll be telling me you use CLSA framework too! But yes, I don't mind having mapping files but I don't like changing my code structure to accommdate a framework...of course that doesn't mean I won't.

     

     

    Wednesday, April 16, 2008 2:26 PM
  • CSLA, i have a book about it somewhere, but I really don't like the framework..

     

    the mapping attributes, meh, it is adding attributes (metadata) to classes..
    It's a given that those attributes don't really belong there, but the benefits are quite large (no xml file to update, a bit easier to read the nhibernate stuff and so on) so i let my purist side sleep

     

    Wednesday, April 16, 2008 2:36 PM