altdotnet at Yahoo! Groups

Re: Wrapper for IOC functions

Glenn Block — Sun, 08 Nov 2009 04:51:37 GMT

In MEF, we (Nick drove this) introduced a concept called PartCreator which is essentially a generic factory that a component takes a dependency.

Re: Wrapper for IOC functions

Morten Maxild — Sat, 07 Nov 2009 15:30:45 GMT

+1 Nice _____ From: altdotnet@yahoogroups.com [mailto:altdotnet@yahoogroups.com] On Behalf Of Mark Seemann Sent: Saturday, November 07, 2009 9:58 AM To:

Re: Wrapper for IOC functions

Patrik — Sat, 07 Nov 2009 12:03:29 GMT

I totally agree with this, and I had to learn this the hard way, starting out using what's now considered an antipattern (static service locator) and moving on

Re: Wrapper for IOC functions

Mark Seemann — Sat, 07 Nov 2009 10:45:18 GMT

In other words; the Hollywood Principle applies: Don't call your DI Container - it'll call you. Mark Seemann http://blog.ploeh.dk

Re: Wrapper for IOC functions

Mark Seemann — Sat, 07 Nov 2009 08:57:56 GMT

You shouldn't need a wrapper, since you should rather strive to make all your code DI Container-agnostic. Contrary to the use of a Service Locator (an

Re: Wrapper for IOC functions

Glenn Block — Sat, 07 Nov 2009 03:12:22 GMT

CSL is not meant to be the uber abstraction / ioc. We designed it only for resolution and not registration. It is there primarily for frameworks that want to

Re: Wrapper for IOC functions

Chris Brandsma — Fri, 06 Nov 2009 22:58:14 GMT

You want the Common Service Locator: http://commonservicelocator.codeplex.com/ But realistically, most of your code (90% or more) should not know that you are

Wrapper for IOC functions

Tariq Hassanen — Fri, 06 Nov 2009 22:31:19 GMT

Hi all, I've been testing several IOC frameworks now and there are alot that seem to suit most scenarios. I've been bitten in the past for choosing a

Re: Overhead for source control, builds, etc

Johnathon Wright — Thu, 05 Nov 2009 19:43:18 GMT

IMHO, the best way to avoid this situation is to release every week to a staging server. That way, when it's time to release to production, the release process

Re: Overhead for source control, builds, etc

Erick Thompson — Thu, 05 Nov 2009 19:19:13 GMT

Perhaps overhead isn't the correct term, as it implies that it doesn't add value. These all add value, without question, but nonetheless they don't directly

Re: Overhead for source control, builds, etc

Erick Thompson — Thu, 05 Nov 2009 19:16:01 GMT

The build/deployment process is what scares me. I've had projects where it has eaten weeks of time. It was a solution that did a build, test, and push to test

Re: hornget

Craig Nicol — Thu, 05 Nov 2009 14:37:27 GMT

Charlie, I'm sure other horn developers will have their own take on this, and I'll let let chip in if they like. We would hope that the developers of each

Re: hornget

Paul Cowan — Thu, 05 Nov 2009 14:36:42 GMT

Hi charlie, I would love more of the bigger oss players to get involved, after all horn is trying to smooth the adoption and delivery of their stuff. At the

Re: Overhead for source control, builds, etc

Johnathon Wright — Thu, 05 Nov 2009 14:10:17 GMT

+1 ... professionals use these tools.

Re: Overhead for source control, builds, etc

Torbjörn Gyllebring — Thu, 05 Nov 2009 08:46:30 GMT

Calling source control and CI "overhead" is about as meaningfull as asking "what is the time overhead of me taking the car 40km to work instead of walking?"