Howard Dierking
howarddierking
-
Extreme ASP.NET Makeover: Mr. Escher, Your Software is Ready - Refactoring NotificationExtreme 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 Si...
-
Extreme ASP.NET Makeover: Mr. Escher, Your Software is Ready - OverviewExtreme 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 stat...
-
Extreme ASP.NET Makeover: Mr. Escher, Your Software is Ready - DependencyExtreme 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 - Host Users Dependency CycleExtreme 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 simp...
-
Extreme ASP.NET Makeover: Mr. Escher, Your Software is Ready - Circular Dependency CycleExtreme 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: Disentangling Our Tangled Web-Overview - OverviewWe’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 creat...
-
Extreme ASP.NET Makeover: Disentangling Our Tangled Web-Overview - RefactoringA 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 ...
-
Extreme ASP.NET Makeover: Singleton - TestabilityExtreme 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 singleton...
-
Extreme ASP.NET Makeover: Singleton - AuthChecker ClassExtreme 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: Singleton - RefactoringExtreme 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, ...
Staff
Here is a list of Channel 9 staff members.
