If you’ve been following me for a while, you’ve likely heard me use the term “N-Tier Architecture” before. Today’s question comes from Arno. He basically asked “What is this N-Tier Architecture thing you keep talking about?”… So, to answer his question, a N-Tier Architecture is one that uses more than one tier. Of course there’s more to it than that…

Very often when we look at a class diagram for a new application, it’s quite overwhelming. There are tons of classes, all interacting with each other. These interactions are everywhere. It actually resembles a spider web of interaction. Trying to decode this web to figure out what the application is doing can be a lesson in futility for some applications.

How then, can we design an application such that it’s easy to follow? How can we build an application that’s easy to understand on all levels? The answer is deceptively simple: by using layers. Let’s explore how we can use layers to help build our applications in a clean, easy to follow and maintainable manner.

A common problem that developers face when building applications is how to allow the application to be “plug-able” at runtime. Meaning, to allow non-core code to modify the way an application is processed at runtime. There are a lot of different ways that this can be done, and lots of examples of it in real life. Over a year ago, I wrote a StackOverflow Answer on this topic. However, I think it deserves another look. So let’s look at some patterns and common implementations.

I recently read a post entitled Dependency Injection: An Analogy, and I think it does a pretty good job explaining two of the types of Dependency Injection. I really like the theme, and feel it really brings down the topic of DI to easy to understand language. The only problem with it that I can see is that there are actually 4 flavors of DI available to us. The other two flavors aren’t even touched in that post. So let me expand on that theme a bit here (Borrowing the same core analogy base from that post):