In this episode Rocky talks to Bob Familiar about why patterns are important, the relationship between patterns and layered architecture and the emergence of MVVM as a key pattern for Rich Internet Applications.

More information on patterns and MVVM can be found on Rocky’s Blog.

You can view the code and read the blog post regarding implementing the pipeline pattern here.  You can download the code at www.robbagby.com.

You can view the code and read the blog post regarding implementing the repository pattern here.  You can download the code at www.robbagby.com. 

You can visit this index of all blog posts and screencasts on Patterns-Based Silverlight.  You can download the code at www.robbagby.com. 

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 instances. Although the Single Responsibility Principle (SRP) would encourage us to have a separate Notification class, our primary job right now is to disentangle Pages and Users. Once the responsibility for notifications has been moved to one class or the other, it can be separated more easily into a separate Notification class. Let’s work on moving it to Pages.

We’ll start by adding notification-related methods on IUsers to IPages (we won’t remove the methods from IUsers or Users yet):

public interface IPages {
    ...
    bool SetEmailNotification(UserInfo user, PageInfo page,
      bool pageChanges, bool discussionMessages);
    bool SetEmailNotification(UserInfo user, NamespaceInfo nspace, 
      bool pageChanges, bool discussionMessages);
    void GetEmailNotification(UserInfo user, PageInfo page, 
      out bool pageChanges, out bool discussionMessages);
    void GetEmailNotification(UserInfo user, NamespaceInfo nspace, 
      out bool pageChanges, out bool discussionMessages);
    UserInfo[] GetUsersToNotifyForPageChange(PageInfo page);
    UserInfo[] GetUsersToNotifyForDiscussionMessages(PageInfo page);
}

We will implement these methods on Pages by temporarily delegating to Users:

public bool SetEmailNotification(UserInfo user, PageInfo page,
                                 bool pageChanges, bool discussionMessages) {
    return users.SetEmailNotification(user, page, 
                                      pageChanges, discussionMessages);
}

The other methods are implemented similarly. We can now look for usages of those methods on IUsers and change them to reference the same methods on IPages instead. The only usages for the IUsers methods should now be by Pages and the IUsers methods can be removed. You’ll have to temporarily cast the IUsers instances in the delegating methods to Users as the methods no longer exist on the IUsers interface:

public bool SetEmailNotification(UserInfo user, PageInfo page,
                                 bool pageChanges, bool discussionMessages) {
    return ((Users)users).SetEmailNotification(user, page,
                                      pageChanges, discussionMessages);
}

Time to pack up the notification-related methods on Users and move them to their new home on Pages.

And That’s a Wrap

Simply by making the dependencies between classes explicit via dependency injection, we revealed a number of circular dependencies lurking in the ScrewTurn Wiki codebase. Circular dependencies between components effectively turn the individual components into one large super-structure, which is difficult to modify. Changes ripple through these super-structures and resulting in unexpected breakages after seemingly innocuous modifications.

Applying the same techniques to Host’s other dependencies, we remove Host’s use of singletons altogether. (For the curious reader, the code is available for download from MSDN Code Gallery for Extreme ASP.NET Makeover.) Host’s constructor signature now looks like this:

public Host(ISettings settings, IAuthWriter authWriter, IUsers users,
         IPages pages, ISnippets snippets, INavigationPaths navigationPaths)

Its dependencies are obvious in a way that they were not before. Host has a fair number of dependencies, but it is acting as a facade between ScrewTurn Wiki and the plug-ins. So it is not overly worrying.

We can start asking ourselves meta questions about our software:

• Do these dependencies make sense?
• Should some of these dependencies be combined/split?
• How do the dependencies relate to one another and can those relationships be improved?

We can reason about the overall structure of our software and improve it because that structure is more apparent. In the end, our software becomes more flexible, more testable, and more resilient in the face of change.

Acknowledgements

I would like to thank Dario Solera, creator of ScrewTurn Wiki, for being brave and open in allowing me to use ScrewTurn Wiki as the brownfield application throughout this series. He has already taken the constructive criticism provided in earlier articles and used it to improve the latest builds of ScrewTurn Wiki. Kudos to Dario for permitting all of us to learn together out in the open.

Thank you to my two occasional co-authors, Kyle Baley and Donald Belcham, for their assistance on parts 6 and 7. Your insights were invaluable in pushing the series forward. Dario has agreed to allow ScrewTurn Wiki to be used as the sample brownfield application for Kyle and Donald’s upcoming book, Brownfield Application Development in .NET, published by Manning. If you want more information about improving brownfield applications, their book is an excellent resource.

A big thanks to Howard Dierking for giving me the latitude and encouragement to take the series where I thought would be most useful and practical. Thanks also to Gary Clarke and the rest of the MSDN Magazine staff for their helpful suggestions, patience, and quick turn-around while editing the series.

Finally, I would like to offer special thanks to my spouse, Risa Kawchuk, and my two sons, Daegan and Gareth, for their understanding in not having as much spouse/daddy time in the last few months as I’ve toiled away evenings and weekends on these articles and screencasts.

Other videos from this article

• Overview
• Dependency
• Host Users Dependency Cycle
• Circular Dependency Cycle
• Refactoring Notification

Read the full article at http://msdn.microsoft.com/magazine/ee470637.aspx

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.

Figure 4 Users Raises Its Own Events

public class Users : IUsers {
  public event 
    EventHandler<UserAccountActivityEventArgs> UserAccountChanged;

  private void OnUserAccountChanged(UserInfo user,
    UserAccountActivity activity) {
      if(UserAccountChanged != null) {
        UserAccountChanged(this, 
          new UserAccountActivityEventArgs(user, activity));
      }
  }

  public event 
    EventHandler<UserGroupActivityEventArgs> UserGroupChanged;

  private void OnUserGroupChanged(UserGroup group,
    UserGroupActivity activity) {
    if(UserGroupChanged != null) {
      UserGroupChanged(this,
        new UserGroupActivityEventArgs(group, activity));
    }
  }
}

Host can now subscribe to the Users.UserAccountChanged and Users.UserGroupChanged events and re-broadcast those events to interested listeners without breaking the facade by exposing the Users class directly, as Figure 5 shows.

Figure 5 Host Can Subscribe to the Users.UserAccountChanged and Users.UserGroupChanged Events

public class Host : IHostV30 {
    public Host(ISettings settings, IUsers users) {
        customSpecialTags = new Dictionary<string, CustomToolbarItem>(5);
        this.settings = settings;
        this.users = users;
        users.UserAccountChanged += OnUserAccountActivity;
        users.UserGroupChanged += OnUserGroupActivity;
    }

    public event EventHandler<UserAccountActivityEventArgs> UserAccountActivity;

    private void OnUserAccountActivity(object sender,
      UserAccountActivityEventArgs args) {
        if(UserAccountActivity != null) {
            UserAccountActivity(this, args);
        }
    }

    public event EventHandler<UserGroupActivityEventArgs> UserGroupActivity;

    private void OnUserGroupActivity(object sender, 
      UserGroupActivityEventArgs args) {
        if(UserGroupActivity != null) {
            UserGroupActivity(this, args);
        }
    }
}

Users no longer needs a reference to Host and it can be safely removed from Users’ constructor. We have broken the circular dependency between Host and Users. Running our tests, we see that everything is green again.

Before we move on, notice how the circular dependency problem wasn’t immediately noticeable when the classes were linked together using Singletons. Singletons, due to their global nature, make it easy for dependencies to spill between classes. Using the dependency injection principle, it is much easier to see a class’s dependencies because most of them are in the constructor and the remainder are method parameters.

Don’t You Forget about IoC

With apologies to Billy Idol, we cannot forget about the container. It is responsible for creating and wiring together our dependencies. Looking at ScrewTurnWikiInitializationTask, we see the following:

Users.Instance = new Users();

Classes that take a dependency on IUsers are going to get an instance of Users supplied through their constructor, but classes that access Users.Instance are going to get a different Users instance. We can solve this minor problem by allowing the IoC container to supply ScrewTurnWikiInitializationTask with an IUsers instance through its constructor. We now have:

public ScrewTurnWikiInitializationTask(IHostV30 host, 
         ISettingsStorageProviderV30 settingsStorageProvider, IUsers users) {
    this.host = host;
    this.settingsStorageProvider = settingsStorageProvider;
    this.users = users;
}

public void Execute() {
    ...
    Users.Instance = users;
    ....
}

While we’re talking about the container, let’s look at HostAnProviderRegistration:

public class HostAndProviderRegistration : IContainerStartupTask {
    public void Execute(IWindsorContainer container) {
        container.Register(
            Component.For<IHostV30>().ImplementedBy<Host>(),
            Component.For<ISettings>().ImplementedBy<Settings>(),
            Component.For<IUsers>().ImplementedBy<Users>());

        ...
    }
}

You’ll notice that we’re starting to get a lot of repetitive code. This is a great place to establish a convention rather than manually configuring each dependency. Let’s create a ScrewTurn.Wiki.Hosting namespace and register each dependency in that namespace against its first interface:

public class HostAndProviderRegistration : IContainerStartupTask {
    public void Execute(IWindsorContainer container) {
        container.Register(
            AllTypes.FromAssembly(Assembly.GetExecutingAssembly())
                .Where(x => x.Namespace.StartsWith("ScrewTurn.Wiki.Hosting"))
                .WithService.FirstInterface()
        );
        ...
    }
}

As we refactor dependencies, we need only place them in this namespace (achieved by moving them to the Hosting folder in ScrewTurn.Wiki.Core) and they will automatically be registered correctly in the IoC container.

The Journey Continues

Users depends on the Settings.Instance and Pages.Instance Singletons. These are quickly extracted into constructor dependencies as before. Pages gets the same treatment as Users—moving to ScrewTurn.Wiki.Hosting namespace (for automatic IoC registration through our convention), interface extraction, and pushing dependent Singletons to constructor parameters. (Additional tests were added to ensure that IPages can be resolved from the IoC container and that Pages.Instance is properly initialized.)

Pages has the same problem as Users in that it uses Host to raise events on its behalf. The same procedure is applied whereby Pages is refactored to raise its own events, which Host then registers for and re-raises to interested listeners. Once again, we’ve broken an unnecessary coupling between two classes, Pages and Host this time. For those interested in the details, you can check out the code download associated with the article.

Pages makes use of many other Singletons and the refactoring continues in much the same vein until we get to Users. Once we move Users into a constructor parameter, our tests break. Pages depends on Users and Users depends on Pages. We’ve uncovered another circular dependency issue. Let’s take a closer look.

Other videos from this article

• Overview
• Dependency
• Host Users Dependency Cycle
• Circular Dependency Cycle
• Refactoring Notification

Read the full article at http://msdn.microsoft.com/magazine/ee470637.aspx

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 matter to continue refactoring away Host’s dependencies on the other Singletons, but trouble is brewing just around the corner. The next Singleton we extract is Users.Instance. Following exactly the same procedure as Settings.Instance, we discover a horrible secret - a CircularDependencyException.

Let’s take a look at the constructors for Host and Users:

public Host(ISettings settings, IUsers users) {
    customSpecialTags = 
        new Dictionary<string, CustomToolbarItem>(5);
    this.settings = settings;
    this.users = users;
}

public Users(IHostV30 host) {
    this.host = host;
}

So Host depends on Users and Users depends on Host. Before the refactoring, this dependency cycle wasn’t obvious. The two components are in fact much more tightly coupled to one another than expected. Let’s take a deeper look at Users to find out where this coupling is coming from.

Other videos from this article

• Overview
• Dependency
• Host Users Dependency Cycle
• Circular Dependency Cycle
• Refactoring Notification

Read the full article at http://msdn.microsoft.com/magazine/ee470637.aspx

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 a morass of dependencies. Before we start refactoring Host, we need some tests in place to ensure that we are not breaking anything. Configuration of the application and infrastructure is done by the ApplicationBootstrapper, which we introduced in Part 8. Our tests are going to execute ApplicationBootstrapper.Configure, as shown in Figure 2, and then verify that IHostV30 can be resolved from the IoC container as well as that various Singletons are still configured properly. Note that the IoC is initialized to null after every test to ensure that the tests don’t interfere with one another.

Figure 2 Tests Execute ApplicationBootstrapper.Configure

[TestFixture]
public class AfterTheApplicationBootstraperIsExecuted {
    [Test]
    public void IHostCanBeResolvedFromTheContainer() {
        IoC.Resolve<IHostV30>();
    }

    [Test]
    public void CacheInstanceIsInitialized() {
        Assert.That(Cache.Instance, Is.Not.Null);
    }

    public void SettingsInstanceIsInitialized() {
        Assert.That(Settings.Instance, Is.Not.Null);
    }

    [Test]
    public void AuthReaderInstanceIsInitialized() {
        Assert.That(AuthReader.Instance, Is.Not.Null);
    }

    [Test]
    public void AuthWriterInstanceIsInitialized() {
        Assert.That(AuthWriter.Instance, Is.Not.Null);
    }

    [SetUp]
    public void SetUp() {
        new ApplicationBootstrapper().Configure();
    }

    [TearDown]
    public void TearDown() {
        IoC.Initialize(null);
    }
}

With these tests in place, let’s start refactoring Host to expose its dependency problems.

Other videos from this article

• Overview
• Dependency
• Host Users Dependency Cycle
• Circular Dependency Cycle
• Refactoring Notification

Read the full article at http://msdn.microsoft.com/magazine/ee470637.aspx

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 classes result in a morass of objects, which is difficult to refactor. Dependency cycles between objects result in sensitive constructor and method orderings, which can lead to unexpected NullReferenceExceptions after apparently innocuous changes to the code. We refactored AuthorizationChecker to eliminate the dependency problems, but we did not address the elephant in the room—ScrewTurn.Wiki.Host. This article confronts the problems of ScrewTurn.Wiki.Host head-on in an effort to tame its wild ways.

Another Look at Host

Host’s primary purpose is to act as a facade between ScrewTurn Wiki’s plug-ins (aka “Providers”) and ScrewTurn Wiki itself. Host allows plug-ins to do everything from retrieving settings values to sending emails to handling backups to finding users, Wiki pages, namespaces, categories, and more, as shown in Figure 1.

Figure 1 IHostV30

The plug-ins, which implement IProviderV30, are initialized with a Host instance and a configuration string through their Init method:

public interface IProviderV30 {
    void Init(IHostV30 host, string config);
    void Shutdown();
    ComponentInformation Information { get; }
    string ConfigHelpHtml { get; }
}

Looking at Host’s constructor, no dependency problems are immediately evident:

public class Host : IHostV30 {
    public Host() {
        customSpecialTags = new Dictionary<string, CustomToolbarItem>(5);
    }
    ...
}

The plug-in system seems fairly innocuous, but the devil is in the details. Let’s dig a little deeper and see what we find.

The First Step is Realizing You Have a Problem

Given Host’s role as a facade object for the plug-in system and its overly simplistic constructor, I suspect that there is a dependency problem lurking beneath the surface. So I have enrolled Host in Dependency-aholics Anonymous. The first step in this twelve-step program is to make Host’s dependencies obvious, just as we did in part 8 when working with AuthorizationChecker.

I’m not too concerned at the moment about static helper classes, such as ScrewTurn.Wiki.Tools or ScrewTurn.Wiki.Formatter. Static helper classes are often a rich source of inspiration for domain concepts. For example, if you have helper methods for performing arithmetic operations on currency, introduce a Money class to encapsulate the data and behavior. If you have helper methods comparing whole dates, introduce a Date class. Yes, .NET has a DateTime class, but it includes both the date and the time. Don’t be afraid to create a Date or Time class that is tailored to the needs of your application. If you deal with financial data, working with a strongly-typed FiscalPeriod class is going to be a lot easier than passing around DateTime objects and remembering to call Helpers.ConvertToFiscal(someDate) to ensure that the DateTime is properly aligned to a fiscal period.

But static helpers aren’t our concern at the moment because these are most often simple stateless methods that have little to no coupling to the rest of the application. We are looking for hidden dependencies that wind their tentacles insidiously throughout the application. The dependencies that have dependencies that have dependencies ad infinitum, resulting in unnecessary coupling and rigidity in the codebase. To find these, we need look no further than the Singletons to which Host delegates much of its responsibilities.

Other videos from this article

• Overview
• Dependency
• Host Users Dependency Cycle
• Circular Dependency Cycle
• Refactoring Notification

Read the full article at http://msdn.microsoft.com/magazine/ee470637.aspx

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 implementations of ISettingsStorageProviderV30, IAuthTools, and IAclEvalator, but we are not concerned with the actual implementations. This is the dependency inversion principle at work.

"High-level modules should not depend on low-level modules. Both should depend on abstractions." – Robert C. Martin (http://objectmentor.com/resources/articles/dip.pdf)

In this case, AuthorizationChecker and AuthTools don’t depend on each other, but depend on the abstraction provided by IAuthTools. The same is true for AuthorizationChecker’s other two dependencies, ISettingsStorageProviderV30 and IAclEvaluator.

We have decoupled AuthorizationChecker from its dependencies. The question remains that AuthorizationChecker still needs these dependencies supplied at run-time to actually be able to execute. The simplest way to supply these dependences as default implementations via AuthorizationChecker's parameterless constructor:

public AuthorizationChecker() : 
    this(Settings.Instance.Provider, 
        new AuthTools(), new AclEvaluator()) {
}

Of Containers and Castles

A more flexible way to supply dependencies is to use an Inversion of Control container, such as Castle Windsor. Castle Windsor is a set of assemblies that we reference from our code. We simply register all of our dependencies in the container and then ask the container for an implementation. The container walks the dependency chain, creates objects in the correct order, supplying dependencies as it creates objects further up the dependency chain until it can finally return us a fully constructed object. Consider the following code:

var authorizationServices = IoC.Resolve<IAuthorizationServices>();

The IoC is a static gateway class that provides an abstraction so that your code is not dependent on a particular IoC container for retrieving dependencies. It is similar in interface and approach to Microsoft’s Common Service Locator available on CodePlex. You can read more about the IoC static gateway in “Loosen Up: Tame Your Software Dependencies for More Flexible Apps”.

In order for Castle Windsor to satisfy this request for an implementation of IAuthorizationServices, we’ll need to register the dependencies:

var ssp = ProviderLoader.LoadSettingsStorageProvider(
    WebConfigurationManager.AppSettings["SettingsStorageProvider"]);
container.Register(
    AllTypes.FromAssembly(Assembly.GetExecutingAssembly())
        .Where(x => x.Namespace.StartsWith("ScrewTurn.Wiki.Services"))
        .WithService.FirstInterface(),
    Component.For<IAclEvaluator>().ImplementedBy<AclEvaluator>(),
    Component.For<ISettingsStorageProviderV30>().Instance(ssp)
);

This code is located in the ScrewTurn.Wiki.Core assembly. Rather than manually configuring each dependency individually, we use a convention-based approach whereby any types in the ScrewTurn.Wiki.Services namespace are registered via their first interface. This means that AuthorizationServices is registered as IAuthorizationServices, AuthTools is registered as IAuthTools, and similarly for other types in this namespace. This has the advantage that by placing services in the ScrewTurn.Wiki.Services namespace, they will automatically be registered in the container without requiring explicit configuration. Other classes can then take dependencies on these services simply by adding the appropriate interface to their own constructor.

AclEvaluator is located in the ScrewTurn.Wiki.AclEngine assembly. Since it is the only dependency in this assembly, we register it explicitly. There isn’t a great deal of value from having a separate assembly for ScrewTurn.Wiki.AclEngine and I would consider merging the AclEngine project into Core. AclEvaluator could then be placed in the ScrewTurn.Wiki.Services namespace and auto-registered like the other dependencies. For the moment, AclEvaluator serves as an example of how to explicitly configure dependencies in Castle Windsor.

ScrewTurn Wiki has code that dynamically loads a particular ISettingsStorageProviderV30 implementation specified by a fully qualified class name in a configuration file. Although we could use Castle Windsor’s configuration facilities to configure and load the appropriate assembly and implementation, that is not the current focus. We can leverage the existing loading mechanism by supplying Castle Windsor with a fully constructed instance via the Component.For<T>().Instance(obj) syntax.

Windsor provides many more configuration options, including overrides, parameters, XML configuration, and more. You can find a lot more information on configuration options in Castle Windsor in my article, Bricks and Mortar: Building a Castle.

Now that AuthorizationServices and all of its dependencies have been registered with the container, we can successfully resolve it from the container:

var authorizationServices = IoC.Resolve<IAuthorizationServices>();

To service this request, Windsor will look for an implementer of IAuthorizationServices, which is AuthorizationServices. Windsor will then examine AuthorizationServices constructor, specifically the constructor parameters:

public AuthorizationServices(IAuthorizationChecker authorizationChecker) {
    this.authorizationChecker = authorizationChecker;
}

Windsor will look to see if it has an implementation registered for IAuthorizationChecker, which it does in the form of AuthorizationChecker. Looking at AuthorizationChecker’s constructors:

public AuthorizationChecker() : this(Settings.Instance.Provider, 
    new AuthTools(), new AclEvaluator()) {
}

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

Windsor has two constructors to choose from. It starts from the constructor with the most overloads. It will see if it has implementations for all of the constructor parameters. (If it can’t find implementations for all constructor parameters, Windsor will attempt the next most overloaded constructor.) In this case, it will see that it needs to find an implementation for ISettingsStorageProviderV30, IAuthTools, and IAclEvaluator. Windsor has an instance of ISettingsStorageProviderV30 that we supplied to it earlier. It can also create instances of AuthTools and AclEvaluator because they have no further dependencies. Windsor passes the newly created AuthTools and AclEvaluator, as well as the pre-built ISettingsStorageProviderV30 to AuthorizationChecker’s constructor. Windsor then passes the newly created AuthorizationChecker to AuthorizationServices’ constructor. Finally, Windsor is able to pass back AuthorizationServices to satisfy the call to IoC.Resolve<IAuthorizationServices>.

Note that Windsor is responsible for managing the lifetime of objects registered in the container. Windsor’s default lifetime strategy is singleton. That means that multiple classes depending on IAuthorizationServices will all receive the same instance of AuthorizationServices. This instancing policy is easily changed on a per-service basis and includes options such as per-thread, per-Web-request, transient, and pooled. You can even create your own instancing policies if none of the built-in ones are appropriate.

With the container responsible for wiring dependencies between objects, we can remove the parameterless constructors as they are no longer required:

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

If AuthorizationChecker required another dependency, we would simply declare that fact by adding another constructor parameter with a type of the required service interface. We would then create a concrete class in the ScrewTurn.Wiki.Services namespace that implements that service interface.

Managing the Container

I have seen many projects place all container configuration into a single XML or C# file. This is especially unwieldy if explicitly configuring dependencies individually, which is why I prefer the convention-over-configuration approach discussed above. By placing dependencies in certain assemblies and namespaces, they are automatically registered. (Note that the convention-over-configuration approach is not available with XML files, although XML files are useful for specifying deployment-time overrides if necessary. For more information about this technique, see Bricks and Mortar: Building a Castle.) Placing all of our conventions in a single C# file can quickly become cumbersome as we have unrelated conventions bundled together.

Let’s take a look at an approach that allows us to separate our conventions into smaller, simpler classes. It all starts with the ApplicationBootstrapper, which is called during application startup:

public void Configure() {
    container = new WindsorContainer();
    IoC.Initialize(new WindsorDependencyResolver(container));

    RegisterFacilityStartupTasks();
    ExecuteFacilityStartupTasks();
    RegisterContainerStartupTasks();
    ExecuteContainerStartupTasks();
    RegisterStartupTasks();
    ExecuteStartupTasks();
}

We start by creating a new WindsorContainer and using it to initialize the IoC static gateway. We then alternately register and execute FacilityStartup, ContainerStartup, and Startup tasks, as shown in Figure 2.

Figure 2 Execute FacilityStartup, ContainerStartup, and Startup Tasks

private void RegisterFacilityStartupTasks() {
    RegisterAllTypesBasedOn<IFacilityStartupTask>();
}

private void RegisterContainerStartupTasks() {
    RegisterAllTypesBasedOn<IContainerStartupTask>();
}

private void RegisterStartupTasks() {
   RegisterAllTypesBasedOn<IStartupTask>();
}

private void RegisterAllTypesBasedOn<T>() {
    assembliesToScan.ForEach(assembly => 
        container.Register(
            AllTypes.FromAssembly(assembly)
                    .BasedOn<T>()
                    .WithService.FirstInterface())
    );
}

The list of assemblies to scan for startup tasks is provided via AssemblyBootstrapper’s constructor and defaults to Assembly.GetExecutingAssembly if left unspecified. We look through each assembly for types implementing IFacilityStartupTask, IContainerStartupTask, and IStartupTask and register them against the appropriate interface. (Facilities are Windsor’s primary extension mechanism. You can use facilities to implement everything from automatic transaction management to logging to array parameter resolution and more.) Next, we need to execute each of the startup tasks:

private void ExecuteFacilityStartupTasks() {
    var tasks = container.ResolveAll<IFacilityStartupTask>();
    tasks.ForEach(task => task.Execute(container));
}

private void ExecuteContainerStartupTasks() {
    var tasks = container.ResolveAll<IContainerStartupTask>();
    tasks.ForEach(task => task.Execute(container));
}

private void ExecuteStartupTasks() {
    var tasks = container.ResolveAll<IStartupTask>();
    tasks.ForEach(task => task.Execute());
}

Note that IFacilityStartupTask|IContainerStartupTask.Execute both take an IWindsorContainer, as their purpose is to configure the container. IStartupTask.Execute is to perform other types of initialization once the container is ready to be used and therefore doesn’t accept an IWindsorContainer.

The individual startup tasks are small and self-contained. For example, take a look at the ServiceRegistration class, which is responsible for registering application-related services:

public class ServicesRegistration : IContainerStartupTask {
    public void Execute(IWindsorContainer container) {
        container.Register(
            AllTypes.FromAssembly(Assembly.GetExecutingAssembly())
                .Where(x => x.Namespace.StartsWith("ScrewTurn.Wiki.Services"))
                .WithService.FirstInterface(),
            Component.For<IAclEvaluator>().ImplementedBy<AclEvaluator>()
        );
    }
}

You can see the convention responsible for registering all services in the ScrewTurn.Wiki.Services namespace. There is also the extra configuration for the AclEvaluator. If we choose to combine the AclEngine project into Core, we could eliminate the extra configuration step for AclEvaluator.

We have a completely separate and independent IContainerStartupTask for Host and Provider registration:

public class HostAndProviderRegistration : IContainerStartupTask {
    public void Execute(IWindsorContainer container) {
        container.Register(
            Component.For<IHostV30>().ImplementedBy<Host>());

        var ssp = ProviderLoader.LoadSettingsStorageProvider(
            WebConfigurationManager.AppSettings["SettingsStorageProvider"]);
        container.Register(
            Component.For<ISettingsStorageProviderV30>().Instance(ssp));
    }
}

As we break apart the “God object” that is the Host, we can modify its container registration in one place without affecting the registration of the services. If we need to perform additional unrelated container configuration, we create another class that implements the IFacilityStartupTask or IContainerStartupTask without affecting other configuration that is already taking place.

To wrap up, let’s refactor StartupTools.Startup() into a IStartupTask where it belongs:

Conclusion

Although it is not initially obvious, the ScrewTurn Wiki codebase suffers from dependency problems. Tight coupling of implementation classes caused by singletons and static classes result in a morass of objects, which is difficult to refactor. Dependency cycles between objects result in sensitive constructor and method orderings, which can result in unexpected NullReferenceExceptions after apparently innocuous changes to the code.

In this article, we have made dependencies obvious by changing them into constructor parameters and using an IoC container to wire together the dependencies. Using convention-over-configuration approaches eases the introduction of new functionality, without requiring explicit configuration. We have introduced a reusable ApplicationBootstrapper, whereby new startup tasks can be added as the application grows without modifying existing code. The resulting codebase should be more flexible and maintainable over time.

Other videos from this article

• Overview
• Refactoring

Read the full article at http://msdn.microsoft.com/magazine/ee424155.aspx

The Tangled Web we Weave

Let’s take a closer look at AuthorizationServices. AuthorizationServices depends on IAuthorizationChecker, which is implemented by AuthorizationChecker. In turn, AuthorizationChecker depends on Settings to retrieve the configured ISettingsStorageProviderV30, which can be a SettingsStorageProvider, SqlSettingsStorageProvider, or other implementation. Now, SettingsStorageProvider depends on IHostV30 and its default implementation by Host. Host is a “God object” in ScrewTurn Wiki. According to Wikipedia, “a God object is an object that knows too much or  does too much.” A God object is a software anti-pattern.

Host is a coordinator of a wide variety of unrelated activities in ScrewTurn. It handles everything from retrieving settings values to sending emails to handling backups to finding users, Wiki pages, namespaces, categories, and more.

Many of these responsibilities are delegated to sub-objects, and Host only acts as the coordinator of these services. This is better than having all that functionality actually coded in Host itself. Host does still present a problem in that its delicate coordination of all the other objects in the system, especially during application startup, means that it is difficult to refactor the overall system. Moving startup code from one class to another causes breakages as the ordering of construction is slightly changed and previously working code throws NullReferenceExceptions as dependencies are unexpectedly null due to construction orderings.

Let’s take a look at Host’s constructor:

public Host() {
    customSpecialTags = new Dictionary<string, CustomToolbarItem>(5);
}

In its constructor, Host creates a single Dictionary. There is no indication that Host has a dependency problem. Host’s tangled web of dependencies is hidden due to its overuse of Singletons and static helper classes. For example, let’s take a look at a few Host methods:

public UserInfo[] GetUsers() { 
    return Users.Instance.GetUsers().ToArray();
}

public PageContent GetPageContent(PageInfo page) {
    return Content.GetPageContent(page, true);
}

public string Format(string raw) {
    return Formatter.Format(raw, FormattingContext.Unknown, null);
}

Note the use of the Users singleton and the static Content an Formatter classes in the above code. Without actually looking at Host’s implementation code, there is no way to tell that it depends on these other classes. To make matters even more complicated, Users (and other dependent classes) depend on Host! If constructors aren’t run in the correct order and before certain methods are called, NullReferenceExceptions will be your reward. All of the construction logic is carefully orchestrated by StartupTools, which is responsible for constructing and initializing all singletons within the application in the correct order.

Seeking Salvation

God objects lead us down a road unto madness. Host’s dependencies are so tangled and interdependent that the result is only somewhat better than a single, monolithic object. So how do we chart a course back to sanity?

Dependencies in software are not fundamentally the problem here. Without dependencies, we wouldn’t be able to write much more than “Hello, World!”-style applications. (Even a simple application like Hello, World!  requires dependencies on System.Console and System.String, as well as the CLR.) The problem is unchecked and unfettered dependencies between objects that do not need to know about each other. Before we can solve the problem of unnecessary dependencies, we need to make those dependencies obvious. How can we construct our classes/objects so that their dependencies are obvious? Make dependencies apparent by declaring them in the classes constructor. For example, let’s look at AuthorizationServices’ constructor:

public AuthorizationServices(IAuthorizationChecker authorizationChecker) {
    this.authorizationChecker = authorizationChecker;
}

Simply by looking at the constructor’s signature, we can tell that AuthorizationServices requires an IAuthorizationChecker to perform its work. (You probably already knew that because we implemented it in part 7.) The concrete implementation of IAuthorizationChecker is AuthorizationChecker:

public AuthorizationChecker() {
    settingsProvider = Settings.Instance.Provider;
}

Notice that you don’t know that AuthorizationChecker depends on the static Settings class. You have to read AuthorizationChecker’s constructor implementation to figure this out. While not hard, it is not immediately obvious that AuthorizationChecker depends on ISettingsStorageProviderV30, which is the type return by the Provider property. How can we make this more obvious? By declaring our intent in the constructor parameters, like so:

public AuthorizationChecker() : this(Settings.Instance.Provider) {
}

public AuthorizationChecker(ISettingsStorageProviderV30 settingsProvider) {
    if(settingsProvider == null)
        throw new ArgumentNullException("settingsProvider");

    this.settingsProvider = settingsProvider;
}

Our other code depends on the parameterless constructor. We will leave it in place for now and chain to an overloaded constructor that takes a ISettingsStorageProviderV30. Our dependency on ISettingsStorageProviderV30 has now been made obvious.

We are not out of the proverbial woods yet. Other dependencies are lurking within AuthorizationChecker, namely the static classes AuthTools and AclEvaluator. We can make them obvious dependencies by changing them from static classes to instances and moving their initialization to the constructor.

Other videos from this article

• Overview
• Refactoring

Read the full article at http://msdn.microsoft.com/magazine/ee424155.aspx

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 not that big of a deal.  As our example, we’re going to continue to refactor the AuthorizationServices class (see the previous Separation of Concerns article for the initial refactoring for this).  In AuthorizationServices, we want to eliminate the use of AuthChecker and, in its place, use an instance of AuthorizationChecker instead.

To do this, we first need to create a module level variable that provides the same capabilities as the AuthChecker singleton.  Earlier in this article, we created an IAuthenticationChecker interface that worked to enforce this for us.  Now is another time that we can use it.  As you can see in the code below, we now have created an instance of the AuthenticationChecker and assigned it to the module level variable:

public class AuthorizationServices
{
    private IAuthorizationChecker _authenticationChecker;

    public AuthorizationServices()
    {
        authorizationChecker = new AuthorizationChecker();
    }
    ...
}

Now that we have a way to access the authentication checking code, we just need to replace the AuthChecker calls in the RetrieveCurrentStatusFor method with calls to the module level variable.  As an example of these changes, here is what the first one would look like:

CanView = _authorizationChecker.CheckActionForPage(currentPage, 
    Actions.ForPages.ReadPage, currentUsername, currentGroups),

With that we have our AuthorizationServices class refactored and we’ve finished the first full round of changes that are required to eliminate the AuthChecker singleton.  If we take a look at the usages of the AuthChecker singleton instance, we’ll see that there are still a large number of places that it is being used.

Now that you’ve finished this first complete refactoring to use the new AuthorizationChecker class, you’ve also reached the first logical checkpoint in your refactoring exercise.  From here you can choose when you want to move from the AuthChecker singleton to an AuthorizationChecker instance class in any of the other places that AuthChecker is being used.  As you incrementally move through your changes from AuthChecker to AuthorizationChecker, you get closer and closer to the next step in this refactoring: deleting the AuthChecker singleton.

Once you have all of the usages of AuthChecker replaced with the AuthorizationChecker class you’re almost ready to remove the AuthChecker class from your code base.  Before we can do that, remember that we had the new AuthorizationChecker class delegating execution to the AuthChecker singleton.  To be able to get rid of AuthChecker completely, we need to move its logic into the new AuthorizationChecker class.  There are a couple of small things that we need to address in this refactoring, such as adding using statements.  

The main change we need is to address the code’s need for an ISettingsStorageProviderV30 typed object.  If we look into how that object is being passed into the AuthChecker singleton, we see that it’s actually being provided from another singleton named Settings:

AuthChecker.Instance = new AuthChecker(Settings.Instance.Provider);

Since this value is coming from a singleton, we can easily add a module level variable to AuthorizationChecker that can be used throughout its methods.  Assigning that variable is as simple as what you see below.  Also note that we no longer need the module level AuthChecker variable since we’ve now moved all of the AuthChecker code into this class.  Since it’s not needed, we’ve removed it and the code related to it in the constructor:

private ISettingsStorageProviderV30 _settingsProvider;
 
public AuthorizationChecker()
{
    _settingsProvider = Settings.Instance.Provider;
}

The result of this final refactoring is that the public methods on AuthChecker are no longer being executed anywhere in the code base.  If you were to do a Find Usages on AuthChecker, you’ll see that the only place it exists is in the StartupTools class where it was being initialized.  Since it’s not being used anywhere, there’s no need to initialize it, so we’ll just delete that line of code.  Now we’re completely free of any use of AuthChecker, so we can delete the class from the project.  With that, you’re free of your singleton past...or at least one part of it.

I realized what a ridiculous lie my whole life has been...

We’ve spent some quality time together on this article and have weaned you from a dependence on singletons in your code base.  Singletons often are seen as the “easy” way to code.  Just because you don’t have to “new up” a class to make use of its functionality, doesn’t mean that you’re not imposing a debt on your code base.  While singletons seem like the route of least friction at first, you quickly find out that they’re nothing more than a mirage on the way to software development bliss.  You see the ease of development that they offer, but every time that you move closer the goal is still just as far away as it was before.

Unless you truly need to ensure that one, and only one, instance of an object exists per application lifecycle, then you should be working to refactor singletons out of your code base.  Hopefully, the techniques in this article have pointed you in the right direction to be able to do that.

Other videos from this article

• Demoing Different Singleton Implementations
• How Singletons Affect Testability
• Looking At AuthChecker
• Walkthrough Of The Entire Refactoring

Read the full article at http://msdn.microsoft.com/magazine/ee343987.aspx

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 continue to be a singleton, since there was no compelling reason for one, and only one, instance of it to exist for the life of the application.

The process that we’re going to go through will see us move from using the existing AuthChecker class to using instances of an AuthorizationChecker class.  Once we’ve made the transition from AuthChecker to AuthorizationChecker, we will delete the AuthChecker Singleton from our codebase.

The first challenge that we have to face in this process is how do we create a new class (AuthorizationChecker) which we can guarantee to expose the same functionality as the original (AuthChecker) class.  There are two reasonable options for this: abstract base class and interface.  Abstract base class is a good solution, if we were going to need to use the same AuthChecker functionality in multiple class implementation for the distant future.  In this case though, we’ve already determined that we’re going to be deleting the AuthChecker Singleton implementation once we’ve completed our refactoring.  As a result, using Interfaces makes more sense.

That makes our first step in the process to extract an interface from the AuthChecker class.  As you can see below, it’s really a simple interface, called IAuthorizationChecker, that defines the four publically exposed methods on the AuthChecker class:

public interface IAuthenticationChecker
{
    bool CheckActionForGlobals(string action, string currentUser,
        string[] groups);
    bool CheckActionForNamespace(NamespaceInfo nspace, string action,
        string currentUser, string[] groups);
    bool CheckActionForPage(PageInfo page, string action,
        string currentUser, string[] groups);
    bool CheckActionForDirectory(IFilesStorageProviderV30 provider, 
        string directory, string action, string currentUser, string[] groups);
}

Now that we have that interface we need to get the AuthChecker to implement it.  This is pretty easy, but has a couple of small twists.  Because we’re applying the interface to a Singleton class, we also have to ensure that the .Instance property is returning a type of the IAuthenticationChecker interface.  To get the code to compile we also have to change the type of the properties underlying module level variable so that it too is of type IAuthorizationChecker:

public class AuthorizationChecker : IAuthorizationChecker
{
    public bool CheckActionForGlobals(string action, 
        string currentUser, string[] groups)
    {
        throw new NotImplementedException();
    }
 
    public bool CheckActionForNamespace(NamespaceInfo nspace, 
        string action, string currentUser, string[] groups)
    {
        throw new NotImplementedException();
    }
 
    public bool CheckActionForPage(PageInfo page, string action, 
        string currentUser, string[] groups)
    {
        throw new NotImplementedException();
    }
 
    public bool CheckActionForDirectory(
        IFilesStorageProviderV30 provider, string directory, 
        string action, string currentUser, string[] groups)
    {
        throw new NotImplementedException();
    }
}

Interestingly, this is the last of the changes that you’ll have to make to AuthChecker before you delete it from the project.

Now that we’ve established how calling code should expect us to behave (via the IAuthorizationChecker interface), we can go ahead and write a new class that meets that expectation.  In this case we’re going to call the class AuthorizationChecker and we’ll make it implement the interface.  The result, as shown in Figure 6, is a class with the same four public methods on it that the AuthChecker class has.

Figure 6 Class With Four Public Methods

public class AuthorizationChecker : IAuthorizationChecker
{
    public bool CheckActionForGlobals(string action, 
        string currentUser, string[] groups)
    {
        throw new NotImplementedException();
    }
 
    public bool CheckActionForNamespace(NamespaceInfo nspace, 
        string action, string currentUser, string[] groups)
    {
        throw new NotImplementedException();
    }
 
    public bool CheckActionForPage(PageInfo page, string action, 
        string currentUser, string[] groups)
    {
        throw new NotImplementedException();
    }
 
    public bool CheckActionForDirectory(
        IFilesStorageProviderV30 provider, 
        string directory, string action, 
        string currentUser, string[] groups)
    {
        throw new NotImplementedException();
    }
}

Now that our new AuthorizationChecker class has a basic shell, we need to get it working with the same functionality as the original AuthChecker singleton.   One of the key things when doing refactorings like this is to be able to do them incrementally.   Big-bang approaches can be successful, but rarely do you have the ability to impose the constraints, such as time and cost, on your project’s current needs.  Instead, we want to be able to nibble away at the refactoring as time permits and in a way that won’t affect the project.

To do this, we’re going to take our new AuthenticationChecker class and simply pass through the calls to the original AuthChecker code.   This may seem like an extraneous step, but it’s one that is necessary to achieve the goal of refactoring little by little.  To make this happen, we need to get an instance of AuthChecker into the local scope of the newly created AuthenticationChecker class:

private IAuthorizationChecker _authChecker;
 
public AuthorizationChecker()
{
    AuthChecker.Instance = new AuthChecker(Settings.Instance.Provider);
    _authChecker = AuthChecker.Instance;
}

Once we have the AuthChecker instance in place, we can have the methods in the class simply delegate execution to the existing methods in the AuthChecker class.  Like we said before, this may seem extraneous, but trust us, we’re going somewhere here, as shown in Figure 7.

Figure 7 Execution of Existing Methods in the AuthChecker Class

public bool CheckActionForGlobals(string action, string currentUser, 
    string[] groups)
{
    return _authChecker.CheckActionForGlobals(action, currentUser,
        groups);
}
 
public bool CheckActionForNamespace(NamespaceInfo nspace, 
    string action, string currentUser, string[] groups)
{
    return _authChecker.CheckActionForNamespace(nspace, action, 
        currentUser, groups);
}
 
public bool CheckActionForPage(PageInfo page, string action, 
    string currentUser, string[] groups)
{
    return _authChecker.CheckActionForPage(page, action, 
        currentUser, groups);
}
 
public bool CheckActionForDirectory(IFilesStorageProviderV30 provider, 
    string directory, string action, string currentUser, string[] groups)
{
    return _authChecker.CheckActionForDirectory(provider, directory, 
        action, currentUser, groups);
}

One of the key things to note with this approach is that we’ve maintained a single place of change for the code that is related to the AuthChecker/AuthorizationChecker functionality.  If we’re going to be tackling this refactoring over a period of time, this is key, since we can’t be confidently maintaining multiple pieces of code that represent the same functionality.  Don’t be fooled that the maintenance cost of this approach is zero.  If you were to change the arguments in the methods, you’d have multiple places to change, but, on a positive note, you’d get compile errors from that due to the use of an interface enforcing the publically exposed contract.

Other videos from this article

• Demoing Different Singleton Implementations
• How Singletons Affect Testability
• Looking At AuthChecker
• Walkthrough Of The Entire Refactoring

Read the full article at http://msdn.microsoft.com/magazine/ee343987.aspx

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. The easiest argument to make is that singletons make your code hard to test. If you make a call to a singleton in a class, then you must make sure the singleton is initialized whenever the test is run. If the singleton requires a connection to a database or the existence of a Web service, these must be configured prior to running the test. If you want reasons why this is a bad practice, look no further than our previous article on separation of concerns.

This lack of testability isn’t the only problem. After all, there are ways (usually neither easy nor pleasant) to make singletons testable. Indeed, ScrewTurn uses one of them by exposing a public constructor. Let’s look more closely at the AuthChecker class we’ve been working with. Why is it a singleton class? Perhaps so that its members can be accessed throughout the site without having to create a new instance of it? Perhaps to save on resources by reducing object allocation and garbage collection? (This would almost certainly be a premature optimization.)

Let’s look at the first public method on the class, CheckActionForGlobals. Where is this being used? If you trace its usages, you’ll find it is used in exactly three other classes: the AdminMaster master page and FileManager.ascx control (both in the WebApplication project) and the AuthorizationServices class in the Core project. (The latter is one of the refactorings we did in Part 6; originally, it was being called in Default.aspx in the WebApplication project.)

So this globally accessible method is really only being used in three places. Doesn’t sound all that global to us. One could make an argument that each of these classes could just create an instance of the class instead. That would make them easier to test and less fragile overall.

Of course, we’ve been cautiously selective in our example. CheckActionForGlobals is but one method in the AuthChecker singleton. If we look at all cases where we reference AuthChecker.Instance, we’ll find no less than 86 occurrences of it across 21 files.

“Aha!” you say. “Doesn’t that contradict your argument that it’s not really being used globally?” “Pshaw!” say we! What it does is highlight another issue with singletons. The Instance variable is used in 21 files, yet CheckActionForGlobals is used in 3. Another method, CheckActionForDirectory, is used in 5, not including calls made from within the AuthChecker class itself.

In short, our singleton has turned into a sort of catch-all bucket, a place to house disparate methods under the loosely-defined category of “authorization checking.” Granted, the AuthChecker class isn’t as messy as it could be, but the tendency with singleton classes is to make them more and more generic as you add “helper” methods to them. The ubiquitous Utils singleton often seen in many projects is a good example. Developers see a singleton and it’s just so darned tempting to drop a method in there rather than create a separate class with a more specific focus.

The result of those temptations is that you find code bases that are littered with unnecessary singletons.  While they may seem innocuous at first, the problems we described earlier will start to haunt your project.  To help you with those existing Singletons, let’s look at how we can move through our code and remove them.

Other videos from this article

• Demoing Different Singleton Implementations
• How Singletons Affect Testability
• Looking At AuthChecker
• Walkthrough Of The Entire Refactoring

Read the full article at http://msdn.microsoft.com/magazine/ee343987.aspx

Let’s review one of the changes we made to the code in part 6. In that discussion, we refactored the authorization checking into a separate class, AuthorizationServices. To do that, we moved a lot of code from the Page_Load method of our Default.aspx page into it. Figure 1 shows an excerpt from the RetrieveCurrentStatusFor method.

Figure 1 Excerpt from the RetrieveCurrentStatusFor Method

return new CurrentCapabilitiesStatus
{
    CanView = AuthChecker.Instance.CheckActionForPage(
        currentPage, Actions.ForPages.ReadPage,
        currentUsername, currentGroups),
    CanDownloadAttachments = AuthChecker.Instance.CheckActionForPage(
        currentPage, Actions.ForPages.DownloadAttachments,
        currentUsername, currentGroups),
    CanSetPerms = AuthChecker.Instance.CheckActionForGlobals(
        Actions.ForGlobals.ManagePermissions,
        currentUsername, currentGroups),
    CanAdmin = AuthChecker.Instance.CheckActionForPage(
        currentPage, Actions.ForPages.ManagePage,
        currentUsername, currentGroups),
    CanViewDiscussion = AuthChecker.Instance.CheckActionForPage(
        currentPage, Actions.ForPages.ReadDiscussion,
        currentUsername, currentGroups),
    CanPostDiscussion = AuthChecker.Instance.CheckActionForPage(
        currentPage, Actions.ForPages.PostDiscussion,
        currentUsername, currentGroups),
    CanManageDiscussion = AuthChecker.Instance.CheckActionForPage(
        currentPage, Actions.ForPages.ManageDiscussion,
        currentUsername, currentGroups),
    CanEdit = canEdit,
    CanEditWithApproval = canEditWithApproval
};

Notice all the calls to AuthChecker.Instance. This is an example of the Singleton Design Pattern at work. We’ll define it now to get everyone on the same page.

There Can Be Only One

The defining characteristic of a singleton class is that there is only one instance of it at any given time (unless it is never used, in which case, there may not be any instances of it depending on how it is implemented).

Implementing a Singleton is not quite as trivial as it sounds. The intuitive approach is to make the constructor private and provide a public static accessor to it, as shown in Figure 2.

Figure 2 Implementing a Singleton

public class MySingleton
{
    private static MySingleton _instance;
 
    private MySingleton()
    {
    }
 
    public static MySingleton Instance
    {
        get
        {
            if (_instance == null)
                _instance = new MySingleton();
            return _instance;
        } 
 
    }
 
    ...
}

This works fine in single-threaded environments, but not in multi-threaded ones. Two threads could enter the Instance property before the instance variable is instantiated, resulting in two instances of the class. There are a few ways around this,  but the easiest solution in .NET takes advantage of the CLR and its guarantees around initialization of static variables, as shown in Figure 3.

Figure 3 Dealing With Two Instances of the Class

public class MySingleton
{
    private static readonly MySingleton _instance = new MySingleton();
 
    private MySingleton()
    {
    }
 

    public static MySingleton Instance
    {
        get
        {
            return _instance;
        } 
 
    }
 
    ...
}

The fact that the instance variable is marked static and readonly ensures only one instance can be created, even in multi-threaded environments.  Another side effect is that an instance of MySingleton is always going to be created for the _instance variable, regardless of if it’s needed or not.  This is, however, rarely an issue in real world code.

Some Background

A common implementation for singletons is to use double-checked locking, like so:

if (_instance == null) {

    lock (_initializationLock) {

        if (_instance == null) {

            _instance = new MySingleton();

        }                    

    }                

}

return _instance;

On the surface, double-checked locking appears to offer the best of all worlds. Singletons are instantiated lazily, are never instantiated if never used, and do not take an expensive lock after the singleton is initialized. Unfortunately, double-checked locking is subtlely broken in the vast majority of cases. You can read more about the problems in The “Double-Checked Locking is Broken” Declaration by David Bacon, et al. Double-checked locking can be fixed on the CLR (and JDK5+) by declaring the _instance variable with the volatile keyword. See Implementing Singleton in C# and Exploring the Singleton Design Pattern in the MSDN Library for more information.

That’s about as detailed as we’re going to get on implementing singletons, because there are a number of good resources already available. Plus, the focus of this article is to move away from them, not add more.

With that background behind us, the “singleton” classes in ScrewTurn aren’t actually singletons. Figure 4 looks at the AuthChecker class first.

Figure 4 AuthChecker Class

public class AuthChecker {
 
    private static AuthChecker instance;

    public static AuthChecker Instance 
    {
        get { return instance; }
        set { instance = value; }
    }
 
    private ISettingsStorageProviderV30 settingsProvider;
 
    public AuthChecker(ISettingsStorageProviderV30 settingsProvider) 
    {
        if(settingsProvider == null) throw new 
            ArgumentNullException("settingsProvider");
 
        this.settingsProvider = settingsProvider;
    }
 
    public bool CheckActionForGlobals(string action, 
        string currentUser, string[] groups) 
    {
   
    }
 
    public bool CheckActionForNamespace(NamespaceInfo nspace, 
        string action, string currentUser, 
        string[] groups) 
    {
   
    }
 
    public bool CheckActionForPage(PageInfo page, string action, 

    {
   
    }
 
    public bool CheckActionForDirectory(
        IFilesStorageProviderV30 provider, 
        string directory, string action, 
        string currentUser, string[] groups) 
    {
   
    }
}

The most obvious way you can tell this isn’t a singleton is that it has a public constructor. So the client code can create as many of these as it likes. Furthermore, the class doesn’t actually instantiate the instance variable itself. That is done elsewhere in the code, in StartupTools.cs, using the public constructor.

That said, it is still used as a singleton within the context of the application. Yes, the code could create more than one instance and re-assign the existing instance and basically treat it like any other class. But in the application’s current state, it doesn’t. This half-way status between singleton and non-singleton would be a bone of contention for us at a code review, so let’s see what we can do to fix it. But first, like any refactoring, we need to justify it.

Other videos from this article

• Demoing Different Singleton Implementations
• How Singletons Affect Testability
• Looking At AuthChecker
• Walkthrough Of The Entire Refactoring

Read the full article at http://msdn.microsoft.com/magazine/ee343987.aspx

Let’s summarize what we’ve done. We removed code from Page_Load using cut and paste, and we created two new classes. It doesn’t seem like much as far as refactoring is concerned. But that’s because we aren’t actually finished with the task. In order to consider the work complete, we must now go to every page that made use of AuthChecker and do the same refactoring as we did here. It will be a lot of work, but the method we used to separate the authorization-specific code can be incrementally applied to other code behind files. Let’s take another look at the refactoring, but this time we’ll see how automated refactoring tools can assist with the changes.

The Big Picture

Once all of the uses of AuthChecker have been removed and AuthorizationService is being used in its place, you will have made the codebase much simpler to work with. Consider now what is involved when we change how permissions are retrieved. Instead of having to find and change the many places that AuthChecker was originally being used (over 130, by our count), you can work only in the AuthorizationServices class. This single point of change shows that you are more likely to be separating the concerns in your codebase.

In the end, a few things have happened from when we first looked at the Default.aspx.cs Page_Load method. First, we have been able to clearly define an area in code for the authorization concern. When anything related to determining a user’s authorization arises, we know that it will be taken care of by the AuthorizationServices. No longer will we continually suffer the ripple effects of modifying or fixing the functionality related to this concern.

Second, we have reduced the number of lines in the Page_Load method, yet through the use of revealing variable and property names, we haven’t reduced the ability for developers to decipher the intentions of the code. This is quite important when doing this type of refactoring. You never want to leave code less understandable than when you found it. (And considering how quickly comments become obsolete, leaving a trail of them behind you to ease understanding is not an optimal approach.)  Instead, think about how you will use variables, properties, and methods in the code and name them so that they read and convey ideas easily.

Conclusion

The final achievement is that we have started a trend of reducing repetition in our codebase. This is a side effect of separating our concerns, but by implementing an isolated class whose sole responsibility is to determine user authorization for a given page, we are allowing ourselves to eliminate any repetitive code that is also doing this. A simple Find search for “AuthChecker” in the entire solution shows that many locations can benefit from using the new AuthorizationServices class.

Taking care of the authorization concern is just one of many refactoring tasks that are available in the Page_Load method of Default.aspx.cs. Others include the URL redirection, the URL builders, Content.GetPageContent, and Settings. If you look through the code provided with this article, you can see how we have refactored those concerns out of Page_Load so that it has one, and only one, reason to change: how we are displaying the contents of the page.

Other videos from this article

• Initial Examination Of Default AspxCs
• Refactoring To AuthorizationServices The Long Way
• Refactoring To AuthorizationServices The Short Way

Read the full article at http://msdn.microsoft.com/en-us/magazine/ee210417

When looking at the code, the first thing that our attention was drawn to was the repetitive nature of the authorization code.  As you can see in the code in Figure 1, there are a large number of calls to retrieve single permission values.

Figure 1 Default.aspx Page_Load Code

string currentUsername = SessionFacade.GetCurrentUsername();

string[] currentGroups = SessionFacade.GetCurrentGroupNames();

bool canView = AuthChecker.Instance.CheckActionForPage(currentPage, Actions.ForPages.ReadPage, currentUsername, currentGroups);

bool canEdit = false;

bool canEditWithApproval = false;

Pages.CanEditPage(currentPage, currentUsername, currentGroups, out canEdit, out canEditWithApproval);

if(canEditWithApproval && canEdit) canEditWithApproval = false;

bool canDownloadAttachments = AuthChecker.Instance.CheckActionForPage(currentPage, Actions.ForPages.DownloadAttachments, currentUsername, currentGroups);

bool canSetPerms = AuthChecker.Instance.CheckActionForGlobals(Actions.ForGlobals.ManagePermissions, currentUsername, currentGroups);

bool canAdmin = AuthChecker.Instance.CheckActionForPage(currentPage, Actions.ForPages.ManagePage, currentUsername, currentGroups);

bool canViewDiscussion = AuthChecker.Instance.CheckActionForPage(currentPage, Actions.ForPages.ReadDiscussion, currentUsername, currentGroups);

bool canPostDiscussion = AuthChecker.Instance.CheckActionForPage(currentPage, Actions.ForPages.PostDiscussion, currentUsername, currentGroups);

bool canManageDiscussion = AuthChecker.Instance.CheckActionForPage(currentPage, Actions.ForPages.ManageDiscussion, currentUsername, currentGroups);

Now, we certainly can’t look at this code and simply say, “Get rid of all that stuff”, because it is necessary for the page to properly function. But how permissions are retrieved, whether from the AuthChecker or Pages or even hard-coding, is the responsibility of some other class, not this one's responsibility.  All Page_Load needs are the final values.

Since we have decided that the Page_Load no longer needs to have intimate knowledge of these details, we can refactor them out. Our first refactoring step is to create a class that is responsible solely for providing the authorization information to the Default.aspx.cs file. We’ll call this class AuthorizationServices. Instead of diving straight into the contents of AuthorizationServices, let’s look at how we want to use it in the Default.aspx.cs Page_Load method. What we want to do is eliminate all of the individual calls to the AuthChecker class and replace them with a single call that returns all of the same authorization information, but in a consolidated fashion. That is, we are looking for something like this:

AuthorizationServices authorizationServices = new AuthorizationServices();

CurrentCapabilitiesStatus currentUser = authorizationServices.RetrieveCurrentStatusFor(CurrentPage);

That single call to AuthorizationServices is what we want to determine what levels of permission are available for the current user. The results of making that method call are returned in a CurrentCapabilitiesStatus object. That object is quite simple and has only properties containing the different authorization values.

SIDEBAR—When refactoring a brownfield application, it often helps to look at things from the client perspective, as we did here. We determined how we want the code to look from the perspective of the Page_Load method in an ideal scenario, and then worked toward making it happen. This is an effective way of isolating the responsibility of a class and separating other responsibilities into other classes.

Now that we know what we want the usage of the code to look like, we can move on to creating those classes and filling them out. Since our refactoring step is to remove the detailed information about the authorization concern out of the Page_Load method, let’s start there. In this case, the simplest refactoring task is to cut and paste the existing AuthChecker calls in the Page_Load code into the RetrieveCurrentStatusFor method.  To make the AuthChecker code compile and function, we will need to move some other code as well. This will include:

string currentUsername = SessionFacade.GetCurrentUsername();

string[] currentGroups = SessionFacade.GetCurrentGroupNames();

var canEdit = false;

var canEditWithApproval = false;

Pages.CanEditPage(currentPage, currentUsername, currentGroups, out canEdit, out canEditWithApproval);

Now that we have all of that code in the RetrieveCurrentStatusFor method, the final step is to create and populate the output object type of CurrentCapabilitiesStatus. As we mentioned before, this is a simple class that contains only properties in it. You may have noticed in an earlier code snippet that we assigned an instance of this object to a variable named “currentUser”. At the time, this may have seemed odd, but when we combine that with the property names, we see that the resulting code in Page_Load becomes more intention-revealing. Since we don’t know what the intended use of the properties are when we’re inside the CurrentCapabilitiesStatus class, let’s step back to the Page_Load method and look at how we intend to use them there.

Chances are, if you did a complete cut and paste from Page_Load to AuthorizationServices.RetrieveCurrentStatusFor, there will be noncompiling code in the Page_Load method now.  This should be limited to the variables that used to be in the method, but are now being moved to the CurrentCapabilitiesStatus class as properties. These are the points of usage that we’re looking for. The first one that you will see is an "if" statement that checks to see if the current user cannot view the current page. Let’s change this to use our “currentUser” variable now.

if(!currentUser.CanView) {

    // body of method remains unchanged

}

This is where you see how using the name currentUser starts to come into play. When scanning this code, it should be clear exactly what we are doing in this method. We have decided to name the property “CanView”, since we are predominantly working with positive questions when using the CurrentCapabilitiesStatus variable type. If you were to go through the rest of the authorization information used, you would end up with properties for CanDownloadAttachments, CanSetPerms, CanAdmin, CanViewDiscussion, CanEditDiscussion, CanManageDiscussion, CanEdit, and CanEditWithApproval, all defined on the CurrentCapabilitiesStatus object.

Once you have those properties added to the CurrentCapabilitiesStatus object and being used in the Page_Load method where needed, we still have one remaining loose end to tie up. While we moved the authorization code from Page_Load to the RetrieveCurrentStatusFor method in AuthorizationServices, we didn’t actually create a CurrentCapabilitiesStatus object and populate it. Doing that property value assignment is the final step in this refactoring.

Other videos from this article

• Initial Examination Of Default AspxCs
• Refactoring To AuthorizationServices The Long Way
• Refactoring To AuthorizationServices The Short Way

Read the full article at http://msdn.microsoft.com/en-us/magazine/ee210417

Separation of concerns is a concept that, when applied to software development, deals with creating distance between dissimilar aspects of your code. This may seem like a complicated statement, but we all have dealt with it in the past, even if we haven’t known it.  You’ve probably heard that you shouldn’t have your data access code in your Web page.  That is separation of concerns.  The Web page shouldn’t directly know how to deal with database concerns like connection strings, command objects, and so on.

Why do we care? Well, separation of concerns is one of the concepts that allows us to work on a specific aspect of an application without having significant impact on other parts of the application.  Think of it this way: Should I be able to work on the engine in my car without having to deal with the wheels?  In our software, we shouldn’t have to deal with the database infrastructure when we’re working in aspx.cs (or aspx.vb) files.

If we aren’t paying attention to separation of concerns, we would start seeing some common issues while working on our codebases.  We’ve all been in a situation where you try to change what appears to be a little thing and end up having to dive deep into the bowels of your application’s infrastructure.  To take a quick example, say you wanted to change how you determine what the user is authorized to do on a page.  In ScrewTurn, permissions are determined through a call to the AuthChecker singleton class. (We’ll discuss how to cure “singletonitis” in an upcoming article. For now, we’ll focus on separation of concerns.) To determine if the user has permission to download an attachment, for example, we make the following call:

AuthChecker.Instance.CheckActionForPage(currentPage,

Actions.ForPages.DownloadAttachments,                                                                   

currentUsername, currentGroups)

If we look at this one line of code on its own, nothing immediately appears to be a problem. But let’s imagine that this call exists in many, or all, of the Web pages in the application.  What we see then is that changing how you determine a user’s ability to download attachments will require you to modify each and every one of those Web pages.  That is, there is a ripple effect of one change imposing the need to modify nonrelated code.

There is another issue at play here. Consider the amount of intimate detail about authorization that exists in the application.  A good example is the Page_Load method in the Default.aspx.cs file.  In Page_Load, there are calls for security information for a given user, including the following:

• Can the user view a page?
• Can the user download attachments on a page?
• Can the user set permissions?
• Can the user administer a page?
• Can the user view discussions on a page?
• Can the user post to discussions on a page?
• Can the user manage discussions on a page?
• Can the user edit a page?

This is a lot of authorization for the Page_Load method to have to know about. Of course, the Page_Load method does need to retrieve and use this information. But our question is this: Does it need to know how to retrieve all of those pieces of information? And just as important, does it need to be done for each individual task that could be performed?  Asked a different way, does Page_Load need to have a full understanding of how security is being handled? No, it doesn’t. Can it simply ask some other class to have all security information given to it? Yes, it can! Page_Load simply needs to get the permissions, and it shouldn’t know or care about the mechanics of how this is accomplished.

Warning: Code Maintenance Ahead

The ultimate goal when applying separation of concerns is maintainability. This being a brownfield application, ScrewTurn Wiki likely has areas that are hard to work with because classes are doing too much and have become fragile. The slightest change to one class has ripple effects throughout the code. By separating concerns, we can break apart the code into its individual pieces so that when you look at a class, you aren’t distracted by extra code that is not part of its responsibility.

This is a good segue into one of the ways you can start separating concerns in your classes. Like many things in our craft, knowing when separation of concerns has been broken is not easy to see. There is one simple thing you can ask yourself when you look at any piece of code:

                Does this code belong in this class?

Or put another way:

                Is this part of the class’s immediate responsibility?

The idea of responsibility is an important one. When we start thinking of separation of concerns and of classes having responsibility, we gravitate toward the Single Responsibility Principle:

                A class should have only one reason to change. – Robert C. Martin in Agile Software Development: Principles, Patterns, and Practices

Earlier, when we were discussing the contents of the Page_Load method in the Default.aspx.cs file, we proposed asking the question, “Does it need to know how to retrieve all of those pieces of information individually?” In our case, the answer should be no.  The Page_Load method should know only that it needs to retrieve authorization information, not the gory details of how that information is retrieved.  Separating those two needs is at the root of determining separation of concerns.

There’s yet another good reason to try to separate concerns in your application. In a previous article, we mentioned user interface testing with WatiN. If you’ve tried setting up UI testing, you’ll quickly discover that it can become cumbersome to create this safety net. The tests are slow and often need to be reworked as the UI changes. By moving code out of the ASPX pages and into separate classes, we open up the testing arena and are able to write true unit tests, ones that test only a single class in isolation, without having to fire up a browser instance, Web server, and database. These tests are faster, less fragile, and can lead us to a place where the code in the ASPX pages is limited to interaction between the various UI widgets.

From Principles to Practice

Enough talk. Let’s take this and apply it to the ScrewTurn Wiki codebase. First, we’ll start with the Default.aspx page’s code behind file. To make things easy, we will start at the top and look at the contents of the Page_Load. This is a busy method and not uncommon for a brownfield application. In this method alone, we can see several responsibilities:

• Redirect the page if necessary
• Determine the user’s rights for the page
• Set up various UI widgets
• Display the contents of the requested wiki page

Other videos from this article

• Initial Examination Of Default AspxCs
• Refactoring To AuthorizationServices The Long Way
• Refactoring To AuthorizationServices The Short Way

Read the full article at http://msdn.microsoft.com/en-us/magazine/ee210417

• A Hierarchical configuration manager, that allows you to store configuration values at the Farm level, allow you to override them in lower levels.
• A generic Service Locator for sharepoint that stores it’s typemappings in config.
• A Sitemap provider that stores it’s sitemap in hierarchical config.
• Reusable workflow activities for SubSite creation, that help you to implement your own SubSite creation process.

With the conclusion of this iteration, the SharePoint Guidance v2.0 project is now feature complete. The next iterations will focus primarily on bug fixes, documentation and quickstarts.
 

Happy Watching!

Happy Watching!