Layer Supertype Pattern

In this post i am going to show another of my favorite pattern called the Layer Supertype Pattern. It’s again a very simple but very useful pattern and was described by Martin Fowler in his famous book Patterns of Enterprise Application Architecture. If you haven’t read this book I strongly recommend you to read this as it will help you in building better Enterprise Applications.

Anyway this is what the definition in the book is :-

It’s not uncommon for all the objects in a layer to have methods you don’t want to have duplicated throughout the system. You can move all of this behavior into a common Layer Supertype.

 

In the past I have implemented various different implementation of this pattern but the common design pattern is that for a layer or suite of component with specialized behaviour we can abstract some behaviour or attribute to a base class so that we can remove some of the duplications.

For example say we are designing a business layer and we have set of business objects the purpose of this layer is to validate domain objects before it can be persisted in a data store. As we can see these business object will encapsulate this functionality from other layers, and its main functionality will be indicate whether the business object itself is valid or not and what the different violation it has from a business rules.

Well that’s a good starting point and things we have identified using our Object Oriented Analysis and Design ( OOAD ) are :-

• Business Rule (holds the rule definition)
• A base entity (to state whether the object is valid and what are the violations
• Business Object ( will implement the Entity Base )

Lets start writing some code :-

BusinessRule.cs

public class BusinessRule
{
   public string Property { get; set; }

   public string Rule { get; set; }

   public BusinessRule(string property, string rule)
   {
      Property = property;
      Rule = rule;
   }
}

EntityBase.cs

public abstract class EntityBase<T>
{
   private readonly List<BusinessRule> _brokenRules = new List<BusinessRule>();
   protected abstract void Validate();

   public IEnumerable<BusinessRule> GetBrokenRules()
   {
      _brokenRules.Clear();
      Validate();
      return _brokenRules;
   }

   protected void AddBrokenRule(BusinessRule businessRule)
   {
      _brokenRules.Add(businessRule);
   }
}

Lets implement a customer class which inherits from the EntityBase class.

Customer.cs

public class Customer : EntityBase<Int32>
{
   public Int32 Id { get; set; }
   public string FirstName { get; set; }
   public string LastName { get; set; }
   public DateTime DOB { get; set; }

   protected override void Validate()
   {
      if (string.IsNullOrEmpty(FirstName))
      {
         AddBrokenRule(new BusinessRule("FirstName","First name cannot be empty"));
      }

      if (string.IsNullOrEmpty(LastName))
      {
         AddBrokenRule(new BusinessRule("LastName", "Last name cannot be empty"));
      }

   }
}

And to complete the task lets write a unit test to check whether we get the desired result or not.

UnitTest.cs

[TestClass]
public class When_using_customer
{
   [TestMethod]
   public void Should_ab_able_to_validate_customer()
   {
      //Arrange
      var customer = new Customer();

      //Act
      var brokenRules = customer.GetBrokenRules().ToList();

      //Assert
      Assert.IsTrue(brokenRules.Count > 0);
   }
}

And now when we run our unit test we get the two broken rules for customer,also if you look at the EntityBase class closely we are using Template method pattern in the GetBrokenRules method which I blogged last year and can be found here.