Essentially the goal is to get away from a “GetOrCreate” master method call and just have two methods: Get(args) and Get(args, Foo default) and then leave the responsibility of default generation up to Foo.  This way there’s no unintended side effects and you don’t have to explicitly coalesce (though with this pattern you could as easily coalesce; strictly speaking it isn’t as “discoverable”)…

var foo = FooService.Get(23) ?? new Foo { ... };

So here’s the pattern defined in code:

public class Foo : ICloneable
{
    private readonly static Foo __default =
        new Foo { Bar = "...", Baz = Int32.MinValue };

    public string Bar { get; set; }
    public int Baz { get; set; }

    public static Foo Default()
    {
        return (Foo)__default.Clone();
    }

    public object Clone()
    {
        return new Foo { Bar = this.Bar, Baz = this.Baz };
    }
}

public class FooService
{
    public Foo Get(int baz)
    {
        // retrieve from data store...
        return null;
    }

    public Foo Get(int baz, Func<Foo> @default)
    {
        return Get(baz) ?? @default.Invoke();
    }
}

You’ll see that any associated overhead with Clone only occurs if Get(baz) returns null.  I have specifically stepped around the common naming standard of “GetDefault()” for the function – its named like a property - because its intended usage is as follows:

var foo = new FooService().Get(12, Foo.Default);

An ICloneable reference type is pretty much required, though any immutable reference type could get by without cloning because any changes gives you a new copy of that type.

public bool Validate(IValidationDictionary modelState, string prefix)
{
    // xVal example code
    var dataAnnotationErrors = from prop in TypeDescriptor.GetProperties(_entity).Cast<PropertyDescriptor>()
           from attribute in prop.Attributes.OfType<ValidationAttribute>()
           where !attribute.IsValid(prop.GetValue(_entity))
           select new ErrorInfo(prop.Name, attribute.FormatErrorMessage(string.Empty), _entity);

    var brokenRules = GetBrokenRules();

    if (!String.IsNullOrEmpty(prefix))
        prefix += ".";

    if (dataAnnotationErrors.Any())
        dataAnnotationErrors.ForEach(ei => modelState.AddError(prefix + ei.PropertyName, ei.ErrorMessage));
    if (brokenRules.Any())
        brokenRules.ForEach(rule => modelState.AddError(prefix + rule.Property, rule.Message));

    return modelState.IsValid;
}

There is a “Fix Indentation” button in PreCode.  I am in love.

Now just to setup the clipboard SWF thing.

I should seriously consider a theme with a wider content area.

http://aspnet.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=22739

I first read about it from Steve Sanderson's blog where he describes how to use it with an ASP.NET MVC project.

I am supporting a legacy web forms application and have a typical web application setup so I'll explain what I did to get up and running in a matter of minutes with LTAF.

1. Download LTAF; you can use the "... for ASP.NET Samples" link and pull the *.dll out of the Bin folder and the contents of the Test folder, or you could build from source using the "... for ASP.NET Source"
2. Create a new Class Library project in your solution and name it appropriately - Company.Tests.Integration.Site - for example
1. For this project's properties alter the output assembly's name to begin with App_Code - this will slightly speed up web test load times and can help solve problems you may experience if your web application references tons of assemblies, i.e. App_CodeCompany.Tests.Integration.Site
3. Add a reference to Microsoft.Web.Testing.Light.dll to your Company.Tests.Integration.Site project
4. Copy and add to your web project (Company.Site) the Test folder; you can name the folder anything you want and you don't strictly have to add it to your project but I did for convenience for Start > Debug
1. Remember to alter your build process to remove the Test folder for production releases
5. Alter the web.config file for your Company.Site to allow anonymous access to the Test folder:

<location path="Test">
  <system.web>
    <authorization>
      <allow users="*" />
    </authorization>
  </system.web>
</location>

1. Again, remember to alter your build process to eliminate this node from your production web.config
6. Add a reference to your integration test project, Company.Tests.Integration.Site, to your web application, Company.Site
7. Let's test the login page (here I assume that "Login.aspx" is the name of your login page and its in the root of the application and you've used an <asp:Login /> control)...
1. Create a new class LoginTests in your Company.Tests.Integration.Site project and eliminate the file's contents - it is very important that all tests exist outside of a namespace
2. Paste this code into the body of your LoginTests.cs file:

using Microsoft.Web.Testing.Light;

[WebTestClass]
public class LoginTests
{
    [WebTestMethod]
    public void SignInAndSignOut()
    {
        var page = new HtmlPage("Login.aspx");

        page.Elements.Find("UserName").SetText("someuser");
        page.Elements.Find("Password").SetText("yourPW");
        page.Elements.Find("LoginButton").Click(WaitFor.Postback);

        // you'll need to determine what a good landmark for your
        // application is upon successful login
        var logoutLink = page.Elements.Find("LogoutHyperlink");
        Assert.AreEqual("[Logout]", logoutLink.GetInnerText());

        logoutLink.Click(WaitFor.Postback);

        Assert.IsNotNull(page.Elements.Find("LoginButton"));
    }
}

8. Set your Company.Site as the startup project if its not already, and Tests/Default.aspx as the startup page; run from Visual Studio

Magic!  This is my first use of a browser automation framework for integration testing and while it has its pitfalls, it does work and looks very promising.

Notes

• Looks like all your integration tests must exist in the same assembly
• Source code for LTAF is available so making this a configuration option is a possibility
• All tests must exist outside of namespaces
• Prefixing your integration tests assembly with App_Code can help work around assembly loading problems as the test runner searches for WebTestClass attributes
• Remember to have your production build process eliminate the Tests folder and associated integration test assembly

The problem with this approach is that the class you want to deep copy requires that it be marked with the SerializableAttribute.  I've noticed that a portion of my time is spent writing hackarounds for classes in the .NET BCL and MailMessage is no exception - yup no ICloneable and no SerializableAttribute either.

public class Serializer
{
    public static void Serialize(Stream target, object source)
    {
        var formatter = new BinaryFormatter();
        formatter.Serialize(target, source);
    }

    public static T Deserialize<T>(Stream source) where T : class
    {
        var formatter = new BinaryFormatter();
        var obj = (T)formatter.Deserialize(source);
        return obj;
    }
}

public class MemorySerializer<T> : IDisposable where T : class
{
    #region Member Variables
    private readonly MemoryStream _ms;
    #endregion

    #region Constructors
    public MemorySerializer(MemoryStream ms)
    {
        _ms = ms;
    }

    public MemorySerializer()
    {
        _ms = new MemoryStream();
    }
    #endregion

    #region Methods
    public MemorySerializer<T> Serialize(T obj)
    {
        Serializer.Serialize(_ms, obj);
        _ms.Position = 0;
        return this;
    }
    public T Deserialize()
    {
        return Serializer.Deserialize<T>(_ms);
    }
    #endregion

    #region Implementation of IDisposable
    public void Dispose()
    {
        if (_ms == null)
            return;
        try
        {
            _ms.Close();
        }
        finally
        {
            _ms.Dispose();
        }
    }
    #endregion
}

public static class ObjectUtility
{
    /// <summary>
    /// Creates a deep copy of an object for any object which
    /// supports binary serialization.
    /// </summary>
    /// <typeparam name="T">Type to serialize/deserialize.</typeparam>
    /// <param name="source">Object to deep copy.</param>
    /// <returns>New instance of the object with all properties and
    /// fields that support serialization copied.</returns>
    /// <remarks>This method isn't as fast as a provided Clone method
    /// but when ICloneable is not implemented on a BCL class its a
    /// pretty close substitute.</remarks>
    public static T DeepCopy<T>(this T source) where T : class
    {
        T ret;
        using (var ms = new MemorySerializer<T>())
        {
            ret = ms.Serialize(source).Deserialize();
        }

       return ret;
    }
}

The solution is quite simple and I figured it out after a bit of trial and error.  What got me was that I had a custom configuration file in a child directory of my unit test project("WebServices") and I had set the configuration file's build action to "Copy Always".  I had thought it would end up in "bin\Debug" but it correctly ended up in "bin\Debug\WebServices" so that's an important thing to keep in mind.

Outsmarting ConfigurationManager also requires that you have an accompanying file (empty text file works) that the configuration applies to.  So here's what the start of my [now working] test looks like:

    private static RequestHandlerSection _section;

    [TestFixtureSetUp]
    public void Setup()
    {
        using (var sw =
            File.CreateText(".\\WebServices\\RequestHandlerTests")
        )
        {
            sw.Close();
        }
        var config = ConfigurationManager.OpenExeConfiguration(
            ".\\WebServices\\RequestHandlerTests"
        );
        _section = (RequestHandlerSection)
            config.Sections[RequestHandlerSection.Name];
    }

    [Test]
    public void WorkDamnYouTest()
    {
        Assert.IsNotNull(_section);
        Assert.IsNotEmpty(_section.Security);
    }
}

Ideally at some point in the future ConfigurationManager could get a Load(string xml) or some such so we don't have to deal with this nonsense.  While I could add one with an extension method I'd like to see it get into the framework to improve unit testability.

1. unless
2. implies
3. templates

unless

Unless is just a reversed if statement.  Its actually quite simple and in some situations it improves code readability.  This is personal opinion more so than anything else, but I feel strongly about it.  Compare:

if (!property.CanRead)
    continue;

to:

continue unless propery.CanRead;

So what it does is remove the negation from the if test (I mean, it is unless after all, isn't it?).  It just flows better.  "Oh, continue unless this condition is met."

implies

Extracting interfaces from existing classes is certainly easier with ReSharper, but I want more.  I don't want to have to maintain separate interface files when the interfaces will match the implementation all of the time.  I understand when you make interfaces and then code the implementation to them however that approach isn't always needed.  I'll give a specific example: unit testing.  I've started using StructureMap and Moq to significantly improve the quality of our tests, but in order to do that I had to StructureMap pluginify all of the IBATIS mappers we have written.  In 100% of the cases the implementation of the mappers are the interfaces of the mappers, and now that I've gone and done this anytime a change needs to be made to a concrete mapper the interface will need to be updated as well - the dependency has been essentially reversed.  I think this scenario will become more common as more people work to improve their unit tests, so I'd like to see something where:

public class PersonMapper : IPersonMapper
{
    public Person Select(int id) { return null; }
    public IList<Person> SelectAll() { return null; }
    public void Create(Person p) { }
    public void Update(Person p) { }
    public void Delete(Person p) { }
}
public interface IPersonMapper
{
    Person Select(int id);
    IList<Person> SelectAll();
    void Create(Person p);
    void Update(Person p);
    void Delete(Person p);
}

becomes:

public class PersonMapper implies IPersonMapper
{
    public Person Select(int id) { return null; }
    public IList<Person> SelectAll() { return null; }
    public void Create(Person p) { }
    public void Update(Person p) { }
    public void Delete(Person p) { }
}

So this isn't a solution for contract by design, its just the opposite, a tightly bound interface to a concrete class.  But what it does do is reduce lines of code and increases maintainability and decreases the pain of writing good unit tests to a degree.  And yes, a tool could be used to do this (I've wrote one in fact), but I'm talking maintainability and ease of use here!

templates

C# generics are very nice, but they are not templates.  Many people who can better articulate the problem than I have argued for them so I'll just post my recent headache as my argument of why I want templates:

private static volatile INodeMapper nodeMapper;

public static INodeMapper Node()
{
    if (nodeMapper == null)
    {
        lock (typeof(INodeMapper))
        {
            if (nodeMapper == null)
                nodeMapper = ObjectFactory.GetInstance<INodeMapper>();
        }
    }
    return nodeMapper;
}

Because nodeMapper is declared volatile you cannot pass it using ref (or even out which would be less ideal than ref).

So imagine that code having to be written for every entity in your database.  Again, a tool can do it, but that's not the correct answer to the problem.  A preprocessor template here would be the only way to do what I want to accomplish in a sane manner.  Until then I've used partial classes to break our mappers down to more maintainable levels (about 2000 lines of repetitious code into several smaller files alphabetically organized).