howarddierking

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…

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…

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…

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…

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…

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,…

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…