Extreme ASP.NET Makeover: A Brownfield Development Series by MSDN Magazine – MSDN Magazine Online (May-September 2009)

Extreme ASP.NET Makeover is a multipart article series about improving an existing “classic” ASP.NET Web application. In this case, James Kovacs will show how to drive incremental improvements in the ScrewTurn Wiki application, with changes ranging from the introduction of automated build scripts to jQuery and AJAX.

1. Getting Your House in Order
2. Testing
3. XHTML and CSS Improvements
4. JavaScript Improvements
5. Web Site Improvements Using jQuery and jQuery UI
6. Separation of Concerns
7. Death of a Singleton
8. Disentangling Our Tangled Web
9. Mr. Escher, Your Software is Ready

Bricks and Mortar: Building a Castle, CoDe Magazine (May/June 2009)

In an application built with object-oriented techniques, objects are the bricks. You construct little pieces of code encapsulated in these bricks. To build bigger structures, you need to hold these bricks together. You can hardwire them together by instantiating dependent objects within your objects, but it makes the whole structure less flexible in the face of change. So you can adopt an inversion of control (IoC) container to act as your mason to assemble your bricks into complex structures that can flex with changing requirements. In this article, I will examine a popular IoC container, Castle Windsor, and how it enables you to build flexible and robust applications. If you are new to IoC containers and dependency injection, I would recommend reading Martin Fowler’s article, Inversion of Control Containers and the Dependency Injection Pattern (http://martinfowler.com/articles/injection.html) and my own article from the March 2008 edition of MSDN Magazine, Loosen Up: Tame Your Dependencies for More Flexible Apps (http://msdn.microsoft.com/en-us/magazine/cc337885.aspx).

IoC Containers perform two basic functions: putting dependencies in and getting fully constructed objects out. I will start by examining how to get fully constructed objects out of your container, and then move on to the more complex aspect of proper configuration of dependencies between objects that you place in the container. (read more…)

Loosen Up: Tame Your Dependencies for More Flexible Apps, MSDN Magazine (March 2008)

Few would disagree that striving for a loosely coupled design is a bad thing. Unfortunately, the software we typically design is much more tightly coupled than we intend. How can you tell whether your design is tightly coupled? You can use a static analysis tool like NDepend to analyze your dependencies, but the easiest way to get a sense of the coupling in your application is to try to instantiate one of your classes in isolation.

Pick a class from your business layer, such as an InvoiceService, and just copy its code into a new console project. Try to compile it. You’ll likely be missing some dependencies, such as an Invoice, InvoiceValidator, and so forth. Copy those classes to the console project and try again. You’ll likely discover other missing classes. When you are finally able to compile, you may find that you have a significant fraction of your codebase in the new project. It’s like pulling on a loose thread and watching your entire sweater fall apart. Every class is directly or indirectly coupled to every other class in your design. Making changes in this type of system is difficult at best because a change in any one class can have a ripple effect throughout the rest of the system. (read more…)

Debug Leaky Apps: Identify And Prevent Memory Leaks In Managed Code, MSDN Magazine (January 2007)

The first reaction many developers have to the idea of memory leaks in managed code is that it’s not possible. After all, the garbage collector (GC) takes care of all memory management, right? The garbage collector only handles managed memory, though. There are a number of places where unmanaged memory is used in Microsoft® .NET Framework-based applications, either by the common language runtime (CLR) itself, or explicitly by the programmer when interoperating with unmanaged code. There are also occasions where the GC seems to be shirking its duties and not efficiently handling managed memory. Usually this is caused by subtle (or not so subtle) programming errors that hinder the GC from performing its job. As good memory citizens, we still have to profile our applications to ensure they are leak-free and make efficient use of the memory they require. (read more…)