Now it took me less than 2 minutes to come to this conclusion…

Just goes to show the P&P team can’t be bothered or can’t be arsed with quality.

Ocne you realise EL is shite you never go back!

#1 – I guess that is because under covers they use ObjectBuilder, which was invented at times when nobody was thinking about SOLID principles. ObjectBuilder is core of EL, so even if at some point they realized the problem, they probably didn’t want to introduce breaking changes. As far as I know they were going to get rid of OB in EL 5.0 and, in fact, latest changeset on codeplex shows that the Teardown method is no longer uses Builder class (though it uses BuilderContext )

#2,3 – I agree, it is quite confusing to get ResolutionFailed while calling something that is not directly related to resolution. The principle was probably same as for Builder class – it can only throw BuildFailedExceptions, UnityContainer can only throw ResolutionFailedExceptions.

2) If the teardown method of the Builder fails, it throws a BuildFailedException, which indicates that the Builder in general only throws BuildFailedExceptions instead of exceptions that are relevant for what actually happened. Don’t you think it would be confusing if you were to get a BuildFailedException when you are _tearing down_ an object?

3) The UnityContainer automatically wraps that BuildFailedException into a ResolutionFailedException. What if the Teardown method failed for different reasons? Suppose that my object and its dependencies couldn’t be cleaned up properly for whatever reason that _doesn’t_ have to do with building or resolving dependencies? See the confusion? This is terrible exception handling practice IMO.

Those are my major problems with this code… the fact that the Builder is new’d up also has me wondering (would it truly be necessary to new up a new Builder for every single operation?) but might not be a big issue. The other ones bother me because they indicate some really poor design decisions IMO, which is even worse considering that this comes from a group called Patterns & Practices. Like it or not, many people in the Microsoft ecosystem will consider everything coming from P&P as ‘the way to go’ and this most certainly isn’t that.

1) The method could be generic. Well, I’m sure PnP guys had some reason for making it non-generic;
2) Rethrowing ResolutionFailedException. Though why not?

And why using something called Builder internally indicates SRP violation?

whether the base implementation does nothing and merely delegates to extensions (which i’d hardly consider ‘doing nothing’) is pretty much irrelevant here… if you’re using extensions, it most certainly does something

the issue is that that piece of code definitely shows a lot… even if you do consider it to be nothing

The UnityContainer class also exposes the Teardown method, which notionally would reverse the build-up process. However, the base implementation of this method does nothing. The implementation exists so that container extensions can execute their own custom overrides of this method if required.

So, what’s the real problem here?

but that’s just one of the design issues that i have with that piece of code…

that’s ‘merely’ a coding error

it’s the design problems that i find troubling

(One could wonder why the ‘new’ up a builder, but that’s for another day.)

which is truly a shame, because that means that this code was written by Microsoft’s PATTERNS AND PRACTICES group