These articles cover all areas of C# and the .NET / dotnet ecosystem. Code examples, tutorials, and different frameworks galore! Dive in!
Background There are two classes available in the .NET framework that sometimes have some confusion around them: The Thread and the BackgroundWorker. They're both used to do some heavy lifting for you on a separate thread of execution (so you can keep on keepin' on), so why do we have two different things to accomplish the same end result Enter The Thread Class The Thread class is available in the System.Threading namespace. Surprising, right? It's the basic unit for spawning off work to be done. Threads let you provide them with a name, which could be one advantage to using them. A thread can either operate as "background" which means it will be killed when the application exists, or not as background, which will actually keep the application alive until the thread is killed off. An instance of the…
Background Previously, I wrote about how events provide you with flexibility in your code. If you take on an event-based paradigm, you can view your system as a group of components that have events execute when certain conditions are met, and less of a procedural view where X always must occur after Y. But what else do events let us do? Decouple your architecture! We all know decoupling is a beautiful thing, so let's see how it's done. How Events Decouple Your Code So the big question then is, how? I'd like to start by providing framing an example architecture. If we assume that we have code that is decoupled by major functionality, we might have some sort of layered architecture. This could mean that we have three layers: presentation, application, and data. These layers would be responsible for…
Before we talk about events... Let's consider that there are many different approaches to developing software. In my opinion, the opposite ends of the spectrum end up being: Knowing how the whole system looks, feels, and operates before coding a single line. Having an idea of what the user wants and coding to make it happen. Although I'm generalizing a lot here, it's sort of like the battle between Waterfall and Agile. Okay, great. So what am I rambling on about here? Well, in the first case, you know all the ins and outs of the system. You can structure your system so that almost no matter how complex it is, you can ensure that method A is always run immediately after method B which is etc... The design is completely controlled. You have a spec for how all the…
