Practical Reflection in .NET
Reflection is an extremely powerful feature of .NET. But there is a big difference between what we can do and what we should do. We'll take a quick look at what reflection is capable of and then narrow our focus to practical uses: balancing flexibility, safety, and performance.When I first saw reflection, I thought it was really cool (and a bit scary, too). And at the time, I didn't think that I would ever use it in my own applications. It really looked like a tool for people who build developer tools or have an extremely specialized situation. But I was wrong.
Reflection is useful for everyday developers, too. Now, it's true that I only use a very small subset of features that reflection offers, but that's probably a good thing. Reflection has some drawbacks -- primarily speed and safety, so we probably want to limit how much we use anyway.
Real World Reflection
I showed a bit of reflection in the C# Interfaces course. In the Dynamic Loading section, we loaded an assembly based on configuration information, and then created an instance of a type. This is reflection. I skipped over the details of reflection since we were focusing on interfaces.
In the latest course, we take a closer look at the reflection parts of this sample so that we can really understand what's going on. This includes looking at the assembly-qualified names that we used in the configuration file, as well as the Type class that loads a type based on that, and the Activator class that we used to create an instance of that type.
Another example shows how we can dynamically load assemblies from the file system and pick out the types that we want. Why would we ever want to do this? Well, the scenario is a rules engine that allows our clients to create their own custom business rules by simply building classes that implement a particular interface. Then they can drop the resulting assemblies into a particular folder that the application picks up automatically. This allows for greater flexibility of our application.
And this technique can be expanded beyond this scenario as well.
The last section of the course covers that scarier parts of reflection. It turns out that nothing in our assemblies is secret. If someone has the assembly, he can look at all of our variables, strings, classes, and functions -- even if they are marked "private". But we shouldn't panic about this, we just need to keep it in mind when we're writing our applications.
There are several techniques that we can use to make sure that our confidential information stays confidential. If you want to learn more about these techniques, be sure to watch the course ;-)
Pluralsight offers tons of great training courses, and they've been expanding immensely over the last year. Pluralsight offers a 10-day free trial that gives you 200 minutes to use however you like. I've also got some free trials that offer 1 week of unlimited usage. So, drop me an email if you're interested.
This is my 5th published course, and I'm working hard on my next one. I've had a lot of fun producing these, and I love to hear from people who have found them valuable (and also from people who have some suggestions -- I'm always trying to make things better).