Friday, November 22, 2013

New Pluralsight Course: Practical Reflection in .NET

My latest course is now available on Pluralsight: Practical Reflection in .NET.

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.

Adding Flexibility
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 ;-)

Wrap Up
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).

Happy Coding!


  1. Jeremy, just a quick note of thanks for the Pluralsight course on reflection, it's terrific. I heartily recommend it to anyone interested in the subject.

    That said, do you have any opinions on using MEF vs reflection in certain circumstances? MEF is the newer kid on the block and it seems there's some overlap between what it does and what reflection provides.

    1. I'm glad that you enjoyed the course. Thanks for letting me know.

      As far as MEF vs. Reflection is concerned... I haven't dug very deeply into MEF, but I have attended several presentations on the topic and read a little bit in various contexts like Dependency Injection and AOP. I've been leaning away from MEF just because there is a little too much "magic" for my taste. This is just a personal preference -- it is a solid technology that lots of people are using.

      In the Dependency Injection world, I lean toward Unity rather than MEF because Unity is a little easier to wrap your head around if you're new to DI. With MEF, we simply place attributes around. This makes for some very compact code that is easy to template, but it is more difficult to debug and to follow what's going on if you're not familiar with MEF or the codebase.

      Again, this is just a personal choice based on the environments that I usually work in (beginning to intermediate level programmers). I know people are using MEF very successfully, and I'm good friends with Dustin who authored the MEF course on Pluralsight. So don't let me steer you away from it.


  2. Thanks for sharing your opinion. I'm a little hesitant about MEF as well, for the reasons you've outlined, and also because (at least as far as I can tell) it hasn't quite 'jelled' yet in the developer community. By that I mean it's been around a little while and isn't a must-have in the DI community, not the way Ninject-Unity-Windsor-Autofac are.

    That doesn't mean it's not worthwhile --plenty of good technology simmers for a bit before taking off (Ruby, for instance)-- but for the moment I haven't heard people shouting it's the go-to for DI work. I don't know much about MEF other than it's an attributed way for joining components, but it sounds interesting. Thanks again for your thoughts, and for the Pluralsight course.