Entries tagged with asp.net - Channel 9

ASP.NET Webcast Teil 4: Durchgaengiges Aussehen: Masterpages, Themes und Skins, Navigation

codefest — Fri, 27 Nov 2009 10:57:00 GMT

Teil 4 der ASP.NET Webcast Serie: Durchgängiges Aussehen: Masterpages, Themes und Skins, Navigation

Weitere auf http://webcast.codefest.at

ASP.NET Webcast Teil 3: Datenbankzugriff, Binden von Daten auf Control, Validierung

codefest — Thu, 19 Nov 2009 15:48:00 GMT

Teil 3 der siebenteiligen Webcast Serie

ASP.NET Webcast Teil 2: ASP.NET Server Controls, Listen, Detailansichten, Controls, Session State

codefest — Fri, 06 Nov 2009 16:21:00 GMT

Teil 2 der Webcast Serie zu ASP.NET.
Die Serie im Überblick auf webcast.codefest.at.

Introducción a ASP.NET AJAX

Channel9Spain — Tue, 03 Nov 2009 00:17:00 GMT

Elisa García Anzano, Academic Developer Advisor en Microsoft Ibérica, nos hace una introducción a ASP.NET AJAX. Un webcast muy práctico en el que Elisa nos muestra las ventajas de usar AJAX, y nos comenta algunas otras cosas como el AJAX Control Toolkit y la librería jQuery.

- Enlaces
http://www.asp.net/ajax
http://www.asp.net/AJAX/AjaxControlToolkit/Samples

ASP.NET Webcast Teil 1: ASP.NET Basisframework & Übersicht, Webforms

codefest — Fri, 30 Oct 2009 12:55:00 GMT

Teil 1 der Webcast Serie zu ASP.NET.
Die Serie im Überblick auf webcast.codefest.at.

MSDN TV - Publicera ASP.NET med Visual Studio 2008

Johan Lindfors — Fri, 23 Oct 2009 13:11:00 GMT

I en serie kortare webcasts så vill jag nu försöka belysa hur enkelt det är att bygga applikationer med Microsofts verktyg och publicera resultatet på svenska “hosters”. I mina exempel använder jag mig av Binero.

I den här filmen publicerar jag en vanlig ASP.NET WebForms applikationer med hjälp av Visual Studio 2008.

Announcing Microsoft Ajax Library Preview 6

James Senior — Fri, 16 Oct 2009 10:47:00 GMT

I sat down with Stephen Walther from the Microsoft Ajax team to talk about their new release - Preview 6 - of the Microsoft Ajax Library.

Stephen walks us through the three big enhancements in this release:

- Addition of the imperative syntax
- The Script Loader
- jQuery support enhancements

We go on to talk about how this will be the last release before we launch the Microsoft Ajax Library before the upcoming Microsoft PDC conference in November and also mention the new Microsoft Ajax CDN where we now have hosted the Microsoft Ajax Library and jQuery.

To download the latest preview and get more information on the Microsoft Ajax Library head over to http://www.asp.net/ajax and also be sure to check out these related blog posts from the rest of the Microsoft Ajax team:

Scott Guthrie has the big announcement
James Senior has details on the Script Loader
Bertrand Le Roy has a blog post on imperative templates

Nya ving.se - en resa i arkitektur

Swedish MSDN Team — Wed, 07 Oct 2009 04:44:00 GMT

Anders Ljusberg, arkitekt på Tomas Cook, berättar om arkitekturen på nya ving.se.

Web Application Toolkit: Template-Driven Emails

Jonathan Carter — Thu, 24 Sep 2009 18:03:00 GMT

This Web Application Toolkit is designed to demonstrate how to generate and send dynamic, template-based emails from a web application. There are many common scenarios where notification emails need to be sent to end users. Examples of these common scenarios may involve notifying a user of their newly created account, sending a new password in respond to a forgotten password request, or emailing an alert under specific business circumstances, such as the creation of a order. Typically the E-mails sent from a Web application scenario are formatted as HTML, include CSS stylesheets, and images and need to be generated dynamically with custom or user-specific data.

This Web Application Toolkit provides a reusable component named TemplateDrivenEmail that can be used to easily generate and send dynamic, HTML-formatted emails based on templates that you can easily create and customize. The TemplateDrivenEmail component is a .NET Class Library that can easily be included in your solution and used with an ASP.NET Web Application, a background application such as a Windows Service, or any other type of .NET application. The email templates are based on a standard XML technology know as Extensible Stylesheet Language. This Web Application Toolkit also includes an example that shows how to use the TemplateDrivenEmail component.

Download this toolkit here.

For screencasts about other Web Application Toolkits, click here.

To download other Web Application Toolkits, click here.

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

Howard Dierking — Fri, 11 Sep 2009 18:18:00 GMT

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 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.

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

Howard Dierking — Fri, 11 Sep 2009 18:17:00 GMT

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.

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.

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

Howard Dierking — Fri, 11 Sep 2009 18:17:00 GMT

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 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.

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

Howard Dierking — Fri, 11 Sep 2009 18:17:00 GMT

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 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.

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

Howard Dierking — Fri, 11 Sep 2009 18:17:00 GMT

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 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.

ASP.NET Databinding and jQueryUI

G. Andrew Duthie — Sat, 05 Sep 2009 23:12:00 GMT

In this installment of DevNuggets, Developer Evangelist G. Andrew Duthie (aka DEvHammer) demonstrates how you can easily add fun and function to your ASP.NET-based website using jQueryUI.

This DevNugget is a follow-up to Andrew's introduction to using jQueryUI in ASP.NET and in it you'll see how easy it is to dynamically generate the markup required to build a jQueryUI Accordion widget using an ASP.NET Repeater control bound to an ADO.NET Data Service. Databinding with a Repeater makes it quick and easy to generate clean markup that's tailor-made for integration with jQueryUI.

You can keep track of what's happening with the DEvHammer on his blog, or on Twitter, and find out about upcoming developer and IT Pro events in your area on his site, Community Megaphone.

Navigating through the hypes, Software architectures and patterns to help avoiding your projects to crash. (Dutch)

Matthijs Hoekstra — Fri, 04 Sep 2009 13:01:00 GMT

When it comes to .Net software development, more and more frameworks enter the market. Both from Microsoft and in open source. Just think of all the very useful frameworks, such as ASP.NET MVC, Castle, WF, Entity Framework, Unity, Linq2SQL, ADO.NET Data Services, WCF, nHibernate, Spring.NET, CSLA, NUnit, Enterprise Library or ADF. Once a project chooses to apply one or more frameworks, trouble begins. What if you require additional features that aren’t implemented in the framework? What if you decide that another framework would have been better and want to switch halfway your project? What if the author of your favorite open source framework suddenly stops developing? What if the framework contains bugs or omissions? And what if a new version of the framework is released that is implemented totally different? These and many more everyday problems will cause your project to come to a halt, or at least make you perform serious refactoring. During this highly interactive talk Sander Hoogendoorn, principal technology officer at Capgemini, chief architect of Capgemini’s agile Accelerated Delivery Platform, and member of Microsoft’s Visual Studio Advisory Board, will demonstrate pragmatic software architectures and patterns that will help your projects to stay away from framework problems, and how to keep your code independent of framework choices. In his well known slightly ironic style Sander will present different models of layered architectures, and explain and use bridge patterns, managers, dependency injection, descriptors, and layer super-types. Of course, the speaker will illustrate these insightful patterns with lots of demo’s and (bad) code examples using blocks from Microsoft’s Enterprise Library, nHibernate, Log4Net, and the Entity Framework. Delegates will benefit from this talk by learning how to improve the structure and quality of their software architecture and code, and how to avoid the pitfalls of applying frameworks to .Net software development.

Deze video is opgenomen tijdens de DevDays in Den Haag in juni 2009. DevDays is het grootste evenement op het vlak van softwareontwikkeling en -architectuur in Nederland. Duizenden development professionals bezoeken dit jaarlijkse evenement om in twee dagen weer volledig op de hoogte te zijn van alle ontwikkelingen op hun vakgebied.

Extreme ASP.NET Makeover: Disentangling Our Tangled Web-Overview - Refactoring

Howard Dierking — Tue, 01 Sep 2009 00:10:00 GMT

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 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.

Extreme ASP.NET Makeover: Disentangling Our Tangled Web-Overview - Overview

Howard Dierking — Tue, 01 Sep 2009 00:10:00 GMT

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 an instance of the AuthorizationChecker class in its constructor by calling the new operator. In this intallment, we will discuss better ways to manage dependencies in our applications using an inversion of control container. If you are not familiar with inversion of control containers or the related concepts of dependency inversion and dependency injection, take some time to read James’ article on those topics from the March 2008 issue of MSDN Magazine, “Loosen Up: Tame Your Software Dependencies for More Flexible Apps.”

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.

ToolShed Tooltip #22 - Channel9 and the Tool Shed ... A Treasure Chest of Resources

Russell Fustino — Mon, 24 Aug 2009 22:49:00 GMT

This Tool Shed Tooltip is about a very valuable resource for all developers... Channel9. Do you know there are other Microsoft communities linked to Channel9 for ASP.NET, Silverlight, IIS, Mix, TechNet Edge and more? Do you know... not every video posted to the channel9 site makes it to the home page? How do you find all of the videos? Do you know you can download a video in many different formats from Zune to High Def for offline viewing? Do you know about the upcoming enhancements to Channel 9? Do you know you can rate videos and provide much wanted feedback? Did you know there is a channel9 toolshed site with links to all of the resources covered in the TV Shows as well as a toolshed code site? Watch this video to learn answers to these questions and many other tips and tricks to optimize your resource experience.

This clip was originally filmed as part of Episode 4 of It's All About The Tools, but it is not included in the final version. So, this is never seen before footage! This was presented in front of a live audience. And even though it was a roomful of Niners... each person I talked to after the event, still walked away learning something. Hopefully you will too!

The show is hosted by Russ Fustino and Co-Host Stan Schultes. Download code, ppt and demo script from http://code.msdn.com/toolshed for all episodes. Also, use the links on http://channel9.msdn.com/toolshed to download tools. Finally, check out some more great videos on the Developer Evangelist East site: http://channel9.msdn.com/dpeeast

Extreme ASP.NET Makeover: Singleton - Refactoring

Howard Dierking — Tue, 04 Aug 2009 23:57:00 GMT

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 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.

Extreme ASP.NET Makeover: Singleton - AuthChecker Class

Howard Dierking — Tue, 04 Aug 2009 23:57:00 GMT

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 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.

Extreme ASP.NET Makeover: Singleton - Testability

Howard Dierking — Tue, 04 Aug 2009 23:57:00 GMT

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. 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.

Extreme ASP.NET Makeover: Singleton - Overview

Howard Dierking — Tue, 04 Aug 2009 23:56:00 GMT

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

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.

Hanselminutes on 9 - ASP.NET MVC 2 Preview 1 with Phil Haack and Virtual Scott

Glucose — Fri, 31 Jul 2009 06:15:00 GMT

Scott's in Redmond (or IS he?) and talking to Phil Haack about the release of ASP.NET MVC 2 Preview 1. Phil give us a tour of some of the new features in this high-tech and inappropriate use of technology. A video of a Phil's screen? Hasn't Scott or Phil heard of a screencast? Still, enjoy. :)
You can download ASP.NET MVC 2 Preview 1 if you like, too.

Jan Welker über dotnet-kicks.de

Dariusz Parys — Mon, 27 Jul 2009 15:43:00 GMT

Auf dem .NET Open Space Süd hatte ich die Gelegenheit mit Jan Welker über das Projekt dotnet-kicks.de zu sprechen. Jan erzählt was letztendlich mit dieser Seite gemacht werden kann und wie es dazu kam das er zusammen mit Gordon und Klaus diese Seite aufgebaut hat.

Viel Spaß beim reinschauen,
Dariusz

Entries tagged with asp.net - Channel 9

ASP.NET Webcast Teil 4: Durchgaengiges Aussehen: Masterpages, Themes und Skins, Navigation

ASP.NET Webcast Teil 3: Datenbankzugriff, Binden von Daten auf Control, Validierung

ASP.NET Webcast Teil 2: ASP.NET Server Controls, Listen, Detailansichten, Controls, Session State

Introducción a ASP.NET AJAX

ASP.NET Webcast Teil 1: ASP.NET Basisframework & Übersicht, Webforms

MSDN TV - Publicera ASP.NET med Visual Studio 2008

Announcing Microsoft Ajax Library Preview 6

Nya ving.se - en resa i arkitektur

Web Application Toolkit: Template-Driven Emails

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

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

And That’s a Wrap

Acknowledgements

Other videos from this article

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

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

Don’t You Forget about IoC

The Journey Continues

Other videos from this article

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

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

Going Around in Circles

Other videos from this article

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

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

Other videos from this article

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

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

Another Look at Host

The First Step is Realizing You Have a Problem

Other videos from this article

ASP.NET Databinding and jQueryUI

Navigating through the hypes, Software architectures and patterns to help avoiding your projects to crash. (Dutch)

Extreme ASP.NET Makeover: Disentangling Our Tangled Web-Overview - Refactoring

A Topsy-Turvy World

Of Containers and Castles

Managing the Container

Conclusion

Other videos from this article

Extreme ASP.NET Makeover: Disentangling Our Tangled Web-Overview - Overview

The Tangled Web we Weave

Seeking Salvation

Other videos from this article

ToolShed Tooltip #22 - Channel9 and the Tool Shed ... A Treasure Chest of Resources

Extreme ASP.NET Makeover: Singleton - Refactoring

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

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

Other videos from this article

Extreme ASP.NET Makeover: Singleton - AuthChecker Class

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

I’ve Got Some Seeds, Right Away

Other videos from this article

Extreme ASP.NET Makeover: Singleton - Testability

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

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

Other videos from this article

Extreme ASP.NET Makeover: Singleton - Overview

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

There Can Be Only One

Some Background

Other videos from this article

Hanselminutes on 9 - ASP.NET MVC 2 Preview 1 with Phil Haack and Virtual Scott

Jan Welker über dotnet-kicks.de