For someone that didn't buy IoC two years ago, you sure changed a lot :-))

I agree with this position 1000% but often there is confusion among the masses, usually coming from a lack of understanding of good OO software design principles.

I always tell my developers that the point of DI, IoC, Interfaces, etc. is to support just the loose-coupling that you mention here. This approach to software design allows easy extensibility points, ONE OF WHICH IS TESTING but that's hardly the only reason for your application's code to be designed for extensibility and flexibility, to be sure.

This kind of thing goes to what I consider to be the true heart of the pro-unit-testing argument: desinging your applicaiton so that it can be unit tested effectively forces you to do the good design work you should already be doing anyway if you really know what you are doing in your profession :)

-Steve B.

Totally agreed with this position. Loose coupling is the goal, although unit testing capabilities is a nice side effect of such a position. The containers also have the benefit of managing the lifetimes of objects, handling interception and so on. Unit testing isn't my main goal when I'm using them, but it makes it nice...

"DI & IoC are about decoupling, better flexibility, having a central place to go to and increasing the maintainability of out applications. "

Seems to me that's what makes it perfect for unit testing.

:-)

Interfaces & Dependency Injection help an application be pluggable(i mean increased decoupling) and then it helps testing. We can say that increased testability is a "desired" side effect.

I'd take it a step further....I hate when people say that Unit Tests are for testing! Unit Tests are meant to be a design tool.....if you are only worried about the testing value than don't write them at all....just use user tests.

Also, can someone tell me why I have read a few others reeling against the term "Dependancy Injection"? To me, this is the most descriptive term for one of the key functions of an IoC!

AJ

DI & IoC are not JUST about testing would be a fairer comment

DI and IoC are quite different things.

DI (using either constructors, members such as properties or why not methods or external classes such as factories) can indeed help testing but the principal useful aspect of it is that it will naturally lead to application of the Single Responsability Principle and usually as well of the Separation Of Concerns Principle.

Because DI is a pain as we end up with a lot of specialized classes IoC can be used to provide flexibility of object graph dependencies management and configuration of individual dependencies.

My personal experience has been that DI through its different forms is something to encourage, now regarding IoC I still sometimes struggle to understand whether it is best to hide the container (I used Castle Windsor) from within a rich object model.

We were recently contracted to take a prototype app and get it ready for their production team. This meant taking what is essentially just spike or proof of concept and making it into a real codebase. The client, a software shop, wanted a list of the tasks we would perform. We discussed using DI to reduce coupling, but that wasn't a strong sell for them. However, they want a unit test suite added, and so that became our "excuse" for using IoC.

It's funny that you mention this. I was just thinking the same thing. Remember all those typemock discussions a few months back? There was a group of people saying that they shouldn't have to write their apps a certain way in order to do testing. I thought that this was odd, because DI, IoC and designing to interfaces have always been about maintainability and flexibility for me. The fact that it is easy to test this kind of code says a lot.

The project manager have told me about a new requirement this week (during development time):

Our web app´s components (services and repositories) should run on another server (not the web server) -- Client´s new Security Policy.

I dont´t know exactly how (usign COM+, .NET Remoting or probably WCF), ***but the point is that those components are totally decoupled,

thanks to Windsor Container (IoC/DI framework) it is gonna be easy.

Bruno,

Actually, changing something to be remote is something that I would be easy about, unless it was designed this way.

Too much chance for chatty interfaces and scalability issues

I haven´t designed it thinking about remoting, in the beginning, but all those components are totally stateless.

What kind of scalability issues are you concerned about?

Thanks!

"Our web app´s components (services and repositories) should run on another server (not the web server) -- Client´s new Security Policy."

Bruno,

The company I work for has been doing that for 10 years. I have a lot of experience with DCOM, Remoting, SOAP, etc. etc. for decoupling web and app layers onto different physical tiers.

After years of doing this, I can assure that you'll never get performance. Everything will be slow, it won't matter how many servers you toss at it. Even a single user will be much slower than you expect.

A better solution which we started implemented about two years ago. Using Microsoft's ISA(or similar) to publish your web app. Then your app runs on an internal server, and ISA is just sending the HTML back and forth across the wire. We also use F5 load balancers here, and I was told the latest version offers similar functionality. We were going to move to that, but budgets got tight.

Mainly,

Chatty interfaces.

Imagine that to render a single page you have to make 15 calls to different services.

No problem if they are on the same server, big issue if they are on different servers

Oh, actually I do not undertand "chatty", but now I got it.

I remeber one of your last posts about creating a method Process( MethodToProcessConfig methodsToProcess) to reduce IO.

May be I should create some kind of "unit of work" handling behind the scene, just like NHibernate does with the database calls

(or find some OSS tool that does it for remote calls).

Do you know some framework that deals with this issues?

Thanks!

Here is the performance POST:

[SOA-Future-Batches]

http://www.ayende.com/Blog/archive/2008/03/07/SOA-Future-Batches.aspx

Thanks!

Bruno,

I am strongly leaning toward NServiceBus for this type of things

OK! Thanks Ayende.

@The Other Steve

I believe it´s better running on the same server too. IIS 7 offers great tools, it´s more than just a web server today.

I´m gonna try to argument about performance.

I´ll check what MS ISA can offer for us, Thanks!

Bruno

@J.P. Hamilton

"There was a group of people saying that they shouldn't have to write their apps a certain way in order to do testing. I thought that this was odd, because DI, IoC and designing to interfaces have always been about maintainability and flexibility for me. The fact that it is easy to test this kind of code says a lot."

I think there are definitely people out there who have found that the ICustomer/IBlahService interfaces often don't pay off in normal application (rather than framework )code.

Doesn't mean we don't use IoC/DI, just means that we don't necessarily use it as much or as early as others and it also probably means that we don't buy into some of the arguments for DI that are normally trotted out. And to be clear it doesn't mean we're against interfaces or dependency inversion, just means we draw the line differently.