Are we using IoC effectively?

Question

So my company uses Castle Windsor IoC container, but in a way that feels \"off\":

• All the data types are registered in code, not the config file.
• All

Answer 1

All the data types are registered in code, not the config file.

By data types I presume you mean the bindings. For example, IFoo should be bound with Foo. If this is the case, that's fine. In fact, this is much better in many peoples eyes (mine included) than specifying bindings via XML. The natural benefit here is that at compile time checks are made. You won't be programming in XML as they say.

All data types are hard-coded to use one interface implementation. In fact, for nearly all given interfaces, there is and will only ever be one implementation.

Are you sure? If so, this could be a smell. However you've stated it's a large application. If there is any unit testing (or automated testing) going on, having an interface per implementation is perfectly valid.

Is my company using IoC effectively? Is there an advantage to new'ing objects with Windsor than new'ing objects with the new keyword?

Yes, from what I can gather. For any form of automated testing, creating a dependency within an object is a bad thing to do. By using an IOC container the complex wiring of classes can be removed when it comes to actually connecting the production code together. This simplifies the application, and allows you as the developer to focus on features, and other tasks, rather than ensuring the whole thing actually builds.

Also, by inverting your control, making changes to modular parts of the application is very easy. For example, imagine if you wished to switch a module for a better version. With IOC containers you simply modify the one or two lines of bindings. Without IOC, you'd have to manually traverse through the application and ensure it was correctly wired internally.

This is a good question that relates to your last point, on why you should use IOC over straight forward manual methods.