Extreme ASP.NET Makeover: Mr. Escher, Your Software is Ready –Refactoring Notification

The circular dependency problem between Pages and Users is due to each class implementing part of a larger notification feature. Once again this was not obvious when the two classes were coupled together via Singleton...

Extreme ASP.NET Makeover: Mr. Escher, Your Software is Ready –Circular Dependency Cycle

The only reason for Users to reference Host is to raise events on behalf of the Users class. We can quickly and easily remove this dependency by allowing Users to raise its own events, as shown in Figure 4.

Extreme ASP.NET Makeover: Mr. Escher, Your Software is Ready –Host Users Dependency Cycle

Going Around in Circles

We successfully refactored away Host’s dependency on Settings.Instance by allowing the IoC container to pass Host an instance of ISettings via its constructor. It seems like a simple...

Extreme ASP.NET Makeover: Mr. Escher, Your Software is Ready –Dependency

As we saw, the Host class delegates to a whole host of Singletons (bad pun intended), including Settings, Users, Pages, Snippets, NavigationPaths, and AuthWriter. Each of these Singletons refers to other Singletons, creating...

Extreme ASP.NET Makeover: Mr. Escher, Your Software is Ready -Overview

We’re now on the ninth installment of Extreme ASP.NET Makeover. In part 8, we discovered that the ScrewTurn Wiki codebase suffers from dependency problems. Tight coupling of implementation classes caused by singletons and static...

A Topsy-Turvy World

The constructor signature for AuthorizationChecker now looks like this:

public AuthorizationChecker(
    ISettingsStorageProviderV30 settingsProvider, 
    IAuthTools authTools, 
    IAclEvaluator aclEvaluator) { ... }

We can clearly see that AuthorizationChecker depends on...

We’re now on the eighth installment of Extreme ASP.NET Makeover. In part 7, we examined the singleton pattern and refactored away the AuthChecker singleton. AuthorizationServices, which previously used the AuthChecker singleton, now depends on the IAuthorizationChecker interface and simply creates...

Extreme ASP.NET Makeover: Death of a Singleton-Refactoring

Now that we have a new class, complete with functionality, we can start to refactor other parts of the application to use it instead of the AuthChecker singleton.  Like all the other refactorings we’ve done thus far in this article, it’s...

Extreme ASP.NET Makeover: Death of a Singleton-AuthChecker Class

I’ve Got Some Seeds, Right Away

So where should we start?  How about the AuthChecker class, since that’s what we’ve discussed through the first part of this article.  Earlier, we decided that there was no reason for it to...

Extreme ASP.NET Makeover: Death of a Singleton-Testability

He’s Liked, But He’s Not Well Liked

If the current code works, why do we need to get rid of the singleton? What harm is it doing? After all, there’s a reason the pattern has a name. It must be useful.

We have a few issues with singletons....