I was reading this article from MSDN on Dependency Injection and I saw a term in the article I didn’t quite understand, to quote:
There are several reasons to use containers in your application development. Containers provide the ability to wrap vanilla objects with a wealth of other services. This allows the objects to remain ignorant about certain infrastructure and plumbing details, like transactionality and role-based security. Oftentimes, the client code does not need to be aware of the container, so there is no real dependency on the container itself.
These services can be configured declaratively, meaning they can be configured via some external means, including GUIs, XML files, property files, or vanilla .NET-based attributes.
I understand that ‘vanilla’ generally refers to something that’s plain, but I don’t exactly understand the meaning here.
What does vanilla refer to in .NET?
Some context would make the question a lot clearer, but usually it’s used to indicate an ordinary object (or type) with no “special powers”. For example, if a serialization scheme claims to work with “vanilla objects” then you shouldn’t need to decorate it with extra attributes etc in order to serialize it. Likewise if an ORM works with vanilla types, it shouldn’t need to implement a specific interface or anything like that.
EDIT: Okay, having seen the context, the above seems to be about right.
Another way of thinking about it is that you can write a type which can then be used by a framework without the type knowing about the framework. So some DI frameworks require you to decorate the types themselves to allow injection, whereas others don’t. The latter frameworks are capable of working with “vanilla” types.