I mentioned Dependency Injection / Inversion of Control (DI/IoC) recently and I really didn't explain what it is, why you might want to use this particular pattern, and why on earth you'd need a framework for it. It's a fancy name for a fairly simple concept. Instead of creating objects inside of your classes, you let the calling code "inject" the necessary instances into your code. It's probably easiest to see this in some code. I'm going to show both C# and VFP code, since I don't want you to get the idea that this is a .NET-only type thing.
 

DEFINE CLASS SampleDependency AS Session 
   FUNCTION SayHello() 
      RETURN "Hello" 
   ENDFUNC 
ENDDEFINE 

DEFINE CLASS Sample AS Session 
   oDepend = NULL 
   FUNCTION Init(toDepend) 
      This.oDepend = toDepend 
   ENDFUNC 
ENDDEFINE 

loSample = CREATEOBJECT("Sample", CREATEOBJECT("SampleDependency"))

Notice that in both cases, we are passing in the instance we want the class to use instead of letting the class create the instance itself. That's all DI/IoC is. Honest, that's it. This is DI via a constructor (you can also do it via a property setting instead; notice in the sample C# code I created a write-only property which could hold the reference).

So the next obvious question is, why? What's wrong with just creating the object inside of the class?

One thing DI gives you is the ability to easily swap in different objects. In the C# example, we probably would change the parameter from a specific type to an interface. Now any class which implements that interface can be injected into this class. In VFP, since it's not strongly typed, you can just pass in whatever instance you'd like (it's up to you to make sure it doesn't blow up at runtime by accessing some method or property which isn't on the passed in object). My initial thought after seeing this was, well, can't I just use an abstract factory pattern instead? In an abstract factory you delegate object creation to a "object factory" - usually passing in a name or calling a method which returns the actual instance you'd like to use. This sounds like almost the same thing.

An abstract factory does let you do that, but it doesn't let you easily do something the DI/IoC pattern does: test your objects. Let's suppose you want to write a test for a class which uses another class to send out an e-mail. You aren't really trying to test sending an e-mail - that's just one of the things the class you're testing happens to do during some process. In fact, you really don't want to send out an e-mail; we don't want to spam our users. If you happen to use the abstract factory pattern, you would need to modify it to create your dummy/stub/mock object for sending an e-mail (in VFP that's most likely by editing a record in a table, but the idea is the same), then test the object in question. If you used the DI/IoC pattern the only thing you need to do is pass in your dummy/stub/mock object. No other modifications are necessary.

OK, so this all looks simple enough. Why would you need a framework for the above?! One of the biggest reasons - less typing. You'll notice that in order to use any of these objects you may have to pass in a bunch of other dependency objects (which themselves may have other dependencies). For a complex set of objects that could really suck. A DI framework does that for you along with the benefits of an abstract factory, all rolled up into one. In your code you call the DI framework and tell it to get you an instance of a class - it figures out what objects need to be passed in for you so you don't need to do it. In your tests, you can instanciate the objects directly and pass in your stub/dummy/mock objects instead.

Links:

http://weblogs.asp.net/rosherove/archive/2007/09/16/mocks-and-stubs-the-difference-is-in-the-flow-of-information.aspx
http://www.hanselman.com/blog/ListOfNETDependencyInjectionContainersIOC.aspx

I've finally gotten all set-up in Microsoft's Empowerment program. I wish I could say it went smoothly, but that definitely wasn't the case. I think I may have signed up at the worst possible time - they were in the process of revamping their website which caused me a bunch of different problems. I finally got tired of playing e-mail tag and called Partner support a few weeks ago. They had been telling me to complete the application process, but every time I tried to log back into the Empowerment site it just told me my application had been denied and it wouldn't let me sign back up (or even tell me WHY it had been denied). When I called they took a look at it then told me they needed to have someone else take a look at the problem. I received an e-mail a few days later claiming the problem should be resolved.

I tried logging back in but had the same problem I had been having. I called them again two weeks ago Monday and while I was on the phone they were finally able to clear whatever flag was keeping me from being able to resubmit my application - they definitely added a few more required fields from when I initially signed up. Last Monday I figured I'd try logging back into the Partner site and see if they had any way of checking the status. I ended up trying to sign up again but this time I got to a page which wanted me to agree to some EULA, but the buttons were all disabled. Was that a good sign or a bad sign?

I found out two days later (on Wednesday) when I received my Empowerment CD's and DVD's. Unfortunately, they don't include any kind of documentation about how to actually get your license keys. Since I've worked at a few places which had their Universal subscription (when it was available), I assumed I might just be able to log into the MSDN subscriber download section using my MS Live ID. I clicked on the "Associate your subscription with your WIndows Live ID" link but it also wanted me to enter my

Benefit Access Number, Subscriber ID, or MSPP Technical Contact ID. Unfortunately I didn't receive anything labeled that way in the kit they sent me. I tried using my partner ID and my MCP ID, neither of which worked. I dug through the partner website and found that I actually had a "Technical ID" associated with my name. To find this - log into the partner site and click on the "Requirements & Assets" menu at the top, then select "Associated People"

At the bottom of the screen that opens is a list of all people associated with your company and their technical ID. I tried entering this and it unfortunately didn't work. I thought (maybe) the site required a Live ID e-mail address instead of my other e-mail address, so I entered it instead and saved it. Then I tried signing in again. At that point the site complained that I had entered the wrong info. in too many times and to try again in 5 minutes. At that point I gave up.

The next day I dug up the MSDN support number and gave them a call. They had me re-enter the information I had tried the night before, fiddled with a few things and suddenly it let me log in!

I know someone who is planning on signing up as well and I'm curious to see if it goes smoother for them than it did for me - hopefully it does.

Links:

http://www.rcs-solutions.com/blog/2007/10/12/MicrosoftsEmpowerProgramForISVs.aspx
http://www.rcs-solutions.com/blog/2007/11/20/EmpowermentProgramUpdate.aspx
https://partner.microsoft.com/40011351
http://msdn2.microsoft.com/en-us/default.aspx

I mentioned in a previous post about signing up for the Microsoft Empowerment program. At the time, they mentioned it may take a while to hear from them. I figured I'd get at least a "hey, we got your application, thanks" e-mail. So far, not a thing. It's not really clear on how (if?) I can even check the status on this.

This was the original signup link: https://partner.microsoft.com/40011351 (strange, my original post should have had this link as well - I wonder where it go lost).

I just checked it again and they mention that the site is undergoing maintenance from 11/8 - 11/30. Great - I wonder if my application ended up in a black hole. I was really hoping to have the licenses taken care of by now, since some of my MS software demos are about to expire.

  I was doing some searching the other day for pricing on MSDN Professional vs MSDN Premium editions, comparing what was included, etc. Pro seemed to be around $1000 vs upwards of $2000 for Premium (depending on the specific version picked). Here's a comparision of the differences. For me, I was really hoping to be able to get Vista, Outlook, and things like Expression. Unfortunately, those are only available with the Premium edition. $1000 was doable, but there was no way I was going to spend $2K on software (it's still not a bad deal, all things considered). I could get the Pro version and just buy what I wanted, but that still pushed the price up to the Premium edition range.

I remember running across some great deals for the MSDN Universal subscription a few years ago on E-bay, so I thought I'd poke around there to see if there was something similar for the Premium edition. I ran across an ad for the Premium version for around $950. "Not bad" I thought, then started looking at the description to make sure it wasn't the Educational version or anything weird. Part of the way down I read some of the requirements: I needed to agree to develop a commercial software app., place a product announcement on my website, make a best effort to pass one of the MS software tests.

Hey! That suddenly started sounding really familiar. Yep, those end up being the same requirements for Microsoft's Empower program. That you can get directly from Microsoft. For $375.

Yep, these guys are really just signing you up for the Empower program for a mere $525 more (handling charge, I guess). Un-Effing believable.