Why we have more than one unique identifier in a table with Sharp Architecture

I was failing to explain to non-OO-aware colleagues about why Sharp Architecture pushes you towards having two unique identifiers on a database table, so I went away, sorted out how to explain Domain Signatures simply in my head, and came up with this explanation. It is hopefully clear, and hopefully correct, so I’ve posted it here to refer back to in future!

There are two reasons:

  1. Ideological: Sharp Architecture is about Domain Driven Design (DDD). A part of DDD is called Persistence Ignorance, the idea is that in order to be usable an entity should not need its database identifier, i.e. you need some way of identifying an object which would work if you were connected to a database or not. This identifier doesn’t need to be another ID code, but you must have a way of uniquely identifying an object (hence the DomainSignature attribute on the property). This allows much easier communication to outside systems too, if necessary, as all systems will know what they are talking about. This article explains it reasonably clearly: http://msdn.microsoft.com/en-us/magazine/dd882510.aspx.
  2. Practical: You cannot easily unit test a method that includes a search for a Sharp Architecture entity that uses Id as the only unique identifier. The Id property is read-only, so you can’t set it in your unit test’s mini ‘database’.

Unit testing MVC’s Authorize attribute with Rhino Mocks

If there is one thing I often forget to do at initial development time, it is to include an Authorize attribute on my controllers to allow only certain specified roles have access. So I’ve added a check to my ‘template’ of controller tests now.

If you have a controller declaration similar to this:

[Authorize(Roles = "Admin")]
public class MyController : Controller
{
    ...
}

Then you can test for the presence of the Authorize attribute in your test class like so (include a reference to System.Web.Mvc):

[Test]
public void Check_Auth_Privileges_Are_Correct()
{

     AuthorizeAttribute attribute = typeof(MyController)
            .GetCustomAttributes(typeof(AuthorizeAttribute), true)
            .Cast<AuthorizeAttribute>()
            .FirstOrDefault();

     Assert.NotNull(attribute); // Check the attribute exists
     Assert.That(attribute.Roles.Contains("Admin"));  // Check it contains your role
     // Check that it doesn't contain any other roles (if necessary)
}

If you have just declared the attribute on a particular method rather than the whole controller then you can test for its presence by just adding an extra line:

[Test]
public void Check_Auth_Privileges_Are_Correct()
{
     var methodInfo = typeof(MyController).GetMethod("MyMethod");
     AuthorizeAttribute attribute = methodInfo
            .GetCustomAttributes(typeof(AuthorizeAttribute), true)
            .Cast<AuthorizeAttribute>()
            .FirstOrDefault();

     Assert.NotNull(attribute); // Check the attribute exists
     Assert.That(attribute.Roles.Contains("Admin"));  // Check it contains your role
     // Check that it doesn't contain any other roles (if necessary)
}

You can obviously use this method for other annotations too.