Anyone know about Dependency Injection?

Post Reply New Topic

I have been reading about it and want to start designing software in that way. Has anyone designed like that?

Dependency injection is one of those concepts that is harder to explain than to do. I like the new book Just Spring which just came out. It explains DI better than anything else I've read. Spring is a Java framework which abstracts out object creation. The basic idea is to remove all the overhead code that creates an object from the object's class and make objects more lightweight. All the overhead code that retrieves an object from a store (like a database, but you can get them from other sources) is kept in the DI framework. If you keep abstracting as much as possible out of the objects, you get a powerful, streamlined framework like Spring that has all the DI code in a mature code base. If you use DI, you get the benefits of all the work done on something like Spring "for free" as it matures (or they just change it randomly to break existing code, which sometimes seems to be the only thing that Java frameworks do), and your objects are lighter and have less code to maintain. Spring has hooks to use with Hibernate (and other ORM tools). I've used Hibernate more than Spring, but Hibernate gives a lot of the same DI benefits if you're using only a database.

Thanks for that reply. I am learning nhibernate now and I suspect that is something easier to use than to explain too. Sometimes though, I fear that programming is getting to be like joining dots rather than writing code.

This all sounds like patterns which are a generalization of objects that have a common structure.

See http://www.objectmentor.com/resources/a ... tterns.pdf

ruveyn

Hibernate is unfortunately not easy to use or explain. I was reading about Microsoft's Entity Framework recently, and it's not easy, either. I guess ORM is just not easy. Hibernate is a bear (now there's a pun) to set up and start using, but if you get up that curve it sort of starts falling into place.

A lot of programming these days is definitely assembling parts into a solution. The world is too complex. Constantly, more and more is being "pushed down" to lower levels and programmers are operating on higher and higher levels of abstraction. That's the only way to grapple with complexity. This has always been the case (C's standard library was once a high-level abstraction), but the complexity of frameworks and libraries these days makes it more of an issue.

Ok I think I get dependency injection, however I think the explanations available for it are poor.

I see it as: designing an object to receive its dependencies from the calling object, rather than have the called object create its own dependencies.

I think we went through this at uni many years back but don't think it was called dependency injection then.

If ORM is what I think it means then it is not difficult if you know SQL, SQLConnections, dataadapters, datsets etc. I am looking at Nhibernate and it seems to me that it just removes the need to know about SQL, so I have yet to see its benefits.

I think you are right about Nhibernate. I spent all day doing a tutorial online and after managing to get it to run without error it doesn't do what it was suppose to do.

It suppose to create a table in a db, but I run it and it says it executed and inserted a record, but when I look at the db there is no such table created!

It seems to me its a complicated way of doing something that was already established and easy to do.

The ideas behind Hibernate (at least the Java version, I've not used NHibernate with .NET but the idea ought to be the same) would include:

a) completely removing your business objects, and even your data access objects, from having any dependency on the underlying database technology being used. With a given Hibernate template you could easily switch your application from SQL server to Oracle, for instance, with nothing but a few configuration changes and not touching your actual compiled source code at all. You should (almost) never write actual SQL when using Hibernate, only HQL.

b) automating the process of serializing / deserializing objects to/from the database, including handling the relationship between objects - i.e. if I want to get information on a single person and the many bank accounts that the person holds, I could just load the person object via Hibernate and so long as Hibernate has been properly configured to be aware of the relationship between a person and bank accounts, it will automatically load the bank accounts too.

As for dependency injection, the general idea is that the responsibility for creating an object's dependencies should not lie within that object. By defining via configurations what dependencies an object has, you can reconfigure what values / objects will be used to populate an object's dependencies independently from your source code.

I have started using Nhibernate now and it seems pretty cool with what I've done so far. However, it was a pain to set up. I'm going to continue using it and hope I'll see the benefit.

ScrewyRabbit - Thanks for your post, it was clear and descriptive. I have read some good comments about Nhibernate and ORMs in general but also read negative ones too. I am still not sure. The benefits seem intangible in a some cases. Like if you have some services accessing your DB and mapping to business objects, why would Nhibernate do it better?

I feel it takes control away from the developer, and I've always liked SQL and working on all levels of an app from UI to DB is required by most jobs I've had.