Joe Gannon

Write, Smell, Refactor

Sat, 15 Oct 2022 00:00:00 +0000

Parallel to the phrase Red, Green, Refactor is what I’ve coined Write, Smell, Refactor ™. It’s a general mindset I find myself in when writing code. This is by no means a hard and fast rule, but it’s something that works for me. I’ll explain what it is and later will go through my thought process of a real world example.

Write

Just as in Red, Green, Refactor, it’s important to get the simplest thing working first. Writing code can be hard enough. So, before you’re code is ultra-pluggable, ultra-flexible, and ultra-sentient, it needs to work first and foremost. Are you doing something with generics? Well, hard code everything and go from there! With the simple things in place you can use it as a jumping off point to improve further. It may also force you to think differently about the problem.

Smell

This one is tricky because it can be hard to agree on what smells or what constitutes “bad code”. It always depends and there’s many interpretations. A good first start is to look at the solid principles, anti patterns, and code smells. I recommend following up with Jeremy Miller’s putting solid into perspective.

Basically, every now and then take a step back and look at the bigger picture. Ask yourself does what I’m doing make sense or do I feel like I’m coding myself into a corner? As you grow as a developer your nose and intuition will naturally get better. You’ll also understand when it’s okay to write “bad code”.

Refactor

There’s a ton to say here and I can’t even begin to scratch the surface. To start I think it’s important to gain a cursory knowledge of the gang of four patterns and refactoring techniques. My personal list of the most important patterns are Builder, Factory, Singleton, Adapter, Decorator, Chain of Responsibility, Command, and Strategy (my personal favorite and in my experience most applicable).

You don’t have to go down the rabbit hole completely with the gang of four patterns and learn everything inside and out. The important part is simply knowing they exist. Seriously, that’s it. Just know they exist and the problems they solve. When a use case comes along you’ll be able to recognize a pattern may fit. It’s common to study these and think you’ll never know when to apply them, but trust me when I say you just will.

Another common mistake is attempting to apply the patterns/principles EVERYWHERE. If you’re like me, you’ll start to think every switch statement and if/else clause is a violation of the open close principle. Or any class with an “AddOrUpdate” method violates Single Responsibility. But those are traps to be avoided, these are principles not rules. It’s important to always be pragmatic.

Putting it Together

In our MVC application we had a lot of html for rendering a grid that was being copied and pasted in multiple places. Inspired by Telerik’s grid helpers I set out to make our own small html helper classes. The result of the below code will be an html table. We’ll be looking at the code that reads and formats the model properties.

@(Html.Grid<WebPageViewModel>()    
    .Columns(columns => {    	
        columns.Bind(x => x.Title);
        columns.Bind(x => x.PageName);
        columns.Bind(x => x.Url);
    }))

Behind the scenes each call to columns.Bind builds a class of TableColumn<TModel, TProperty>. The GetValue function is particularly noteworthy. Right now it only returns our property as a string (the simplest thing), later we want to format hyperlinks, textboxes, etc.

public class TableColumn<TModel, TProperty>
{ 
    public Func<TModel, TProperty> GetProperty { get; set; }

    public TableColumn(Func<TModel, TProperty> getProperty)
    {
        GetProperty = getProperty;
    }

    public string GetValue(TModel model)
    {
        var value = GetProperty(model).ToString();

        return value;
    }
}

Expanding the code to allow our properties to be formatted as a textbox or hyperlink results in something like this.

@(Html.Grid<WebPageViewModel>()    
    .Columns(columns => {    	
        columns.Bind(x => x.Title);
        columns.Bind(x => x.PageName).TextBox();
        columns.Bind(x => x.Url).HyperLink("display text");
    }))

public class TableColumn<TModel, TProperty>
{ 
    public bool TextBox = false;
    public bool HyperLink = false;
    public string LinkText = "";

    public Func<TModel, TProperty> GetProperty { get; set; }

    public TableColumn(Func<TModel, TProperty> getProperty)
    {
        GetProperty = getProperty;
    }

    public string GetValue(TModel model)
    {
        var value = GetProperty(model).ToString();

        if (TextBox)
        {
            value = $"<input type=\"text\" value=\"{value}\">"
        }
        else if (HyperLink)
        {
            value = $"<a href=\"{value}\">{LinkText}</a>";
        }

        return value;
    }
}

How does it hold up to the smell test?

It’s not exactly the worst code in the world, but there’s room for improvement. The main issue I see (besides poor encapsulation) is that this class will grow linearly with every new feature. Each new format will require new properties and an additional else if clause inside the GetValue function. GetValue also violates the open close principle and with enough of these features this class can quickly become a large class.

We’ll also have to consider how client code will interact with this class. A class like this can be difficult to work with if it requires specific permutations of properties to function properly.

Refactoring

At the end of the day all the code is doing is preparing some text/html to be rendered inside a td tag and based on some conditions we want that rendered output to be different.

Hmmm, that actually sounds a lot like a design pattern I’m familiar with. Oh, that’s right it’s the strategy pattern! And yes, now I remember the strategy pattern is one way of solving open close violations!

After refactoring towards the strategy pattern we’ve now got something that leads to less class bloat and allows client code to have an easier time using our object.

public class TableColumn<TModel, TProperty>
{ 
    private RenderStrategy _renderStrategy;

    public Func<TModel, TProperty> GetProperty { get; set; }

    public TableColumn(Func<TModel, TProperty> getProperty)
    {
        GetProperty = getProperty;
        _renderStrategy = new DefaultRenderStrategy();
    }

    public string GetValue(TModel model)
    {
        var value = GetProperty(model).ToString();

        value = _renderStrategy.Render(value);

        return value;
    }

    public void SetRenderStrategy(RenderStrategy renderStrategy)
    {
        _renderStrategy = renderStrategy;
    }
}

public interface RenderStrategy 
{
    string Render(string value);
}

public class DefaultRenderStrategy : RenderStrategy 
{
    public string Render(string value) => value;
}

public class TextBoxRenderStrategy : RenderStrategy 
{
    public string Render(string value) => $"<input type=\"text\" value=\"{value}\">";
}

public class HyperLinkRenderStrategy : RenderStrategy 
{
    private string _linkText;

    public HyperLinkRenderStrategy(string linkText)
    {
        _linkText = linkText;
    }

    public string Render(string value) => $"<a href=\"{value}\">{_linkText}</a>";
}

How to Write a WoW Addon

Sun, 18 Aug 2019 00:00:00 +0000

So you want to write a WoW addon? Well, you better get used to crappy docs, old websites, and skimpy examples. The fact that it’s all community driven and nothing official from Blizzard doesn’t make it any easier. I recently wrote my first addon for classic called Track Sales, so I know your pain. It’s not all doom and gloom though, there’s really only a few key concepts to understand and everything else falls into place. Though this guide isn’t specific to retail or classic, please use the retail version to follow along. The version I wrote this with is 80200.

First and foremost, if you’re struggling with your addon, the best advice I could give you is not to google, not to read the docs, not to read this post, but to read other addons! I’ve found hands down that has been the best way to learn how to do things. Generally, googling and reading docs are great tools but when developing Track Sales nothing was better than seeing how other people did things. Aim for smaller addons that will be easier to understand. Reading other people’s code is always an excellent way to learn (for anything). You’ll be amazed at the things you can learn just from reading someone else’s code. Clone your favorite open source project and check it out someday!

Hello Azeroth

We’ll start with a Hello World example. In _retail_/Interface/Addons create a folder named MyAddon, inside create a lua file named MyAddon.lua. Place this statement print("Hello Azeroth") in the file.

Next we need to tell WoW about our addon, this is done in the toc file. Create a new file named MyAddon.toc and add the below snippet.

# Your client version is probably different than 80200
# In game run "/run print((select(4, GetBuildInfo())))" and use that for the interface number

## Interface: 80200
## Version: 1.0.0
## Title: My Addon 
## Notes: My First Addon
## Author: You 

MyAddon.lua
# additional lua files

This tells WoW what client version our addon supports (if the current version is newer than 80200 you’ll see the “addon out of date” message), our addon name, and the files our addon needs. We’ll come back to the toc file later but for now load up WoW. On the character select screen check to see My Addon is listed in the addon menu. If it isn’t then double check that everything is correct. When you load into the game you should see “Hello Azeroth” appear in the chat.

Key Concepts

Building an addon can really be boiled down to these concepts. The rest is filling in the details of your addon.

Events
Hooks
Saved Variables
Ace (3rd party helpers, optional)
Console Commands
UI (sorry, I won’t be covering this, see Extended Character Stats for ideas)
Testing

Events

Events are fired when various actions happen in the game world ie open mail, learned a new spell, etc. We can register to events with the code below.

MyAddon = { }

local frame = CreateFrame("Frame")
frame:RegisterEvent("MAIL_SHOW")
frame:RegisterEvent("AUTOFOLLOW_BEGIN")

-- this syntax doesn't work in classic * 
frame:SetScript("OnEvent", function(this, event, ...)
    MyAddon[event](MyAddon, ...)
end)

function MyAddon:MAIL_SHOW()
    print("Mail Shown")
end

function MyAddon:AUTOFOLLOW_BEGIN(...)
    local player = ...
    print("Following "..player)
end

MyAddon = { } is essentially just a namespace. Lua doesn’t actually have namespaces but it’s the same concept as many languages such as c#, java, and c++. With this we can avoid using global variables.

Unfortunately, I can’t share much about CreateFrame other than “this is how you register events”. You’ll also use frames if you want to create a UI.

I have no idea what that crazy SetScript syntax is I just know that’ll dispatch all events efficiently. It works by convention so you’ll have to make sure the function name matches the event name. If you don’t want to be restriced to that convention AceEvent can help.

When you open the mailbox and start following a player you should see the messages appear. You can find other events here.

Hooks

Hooks are very similiar to events except that hooks fire before or after the original function (the built in WoW function). Hooks allow you to modify the parameters that get passed to the original function or if you wish, not call the original function at all…so you could really mess things up. “Secure Hooks” are the safe version to use. To create a hook we’ll use hooksecurefunc which is a “safe post-hook”, for your use case you may need pre or post hooks, docs.

MyAddon = { }

hooksecurefunc("PickupContainerItem", function(...) MyAddon:PickupContainerItem(...) end)
hooksecurefunc("TakeInboxMoney", function(mailId) MyAddon:TakeInboxMoney(mailId) end)

function MyAddon:PickupContainerItem(container, slot)    
    local _, _, _, _, _, _, link = GetContainerItemInfo(container, slot)

    print(link)
end

function MyAddon:TakeInboxMoney(mailId)   
    local _, _, sender, subject, money = GetInboxHeaderInfo(mailId)    
    
    print("Sender "..sender, "Subject "..subject, "Money "..money)
end

GetContainerItemInfo and GetInboxHeaderInfo are WoW apis, you can find other functions here. If you LEFT click an item in your inventory you should see it’s item link printed. To test TakeInboxMoney send some gold to an alt and loot it from mail. Don’t autoloot it! That would need the AutoLootMailItem hook. If it’s not working, try disabling other addons and try again. There can be some intricacies to hooks, see the notes section. Alternatively, try the AceHook package.

Saved Variables

SavedVariables are values saved to disk that can be used between game sessions. The values are stored in the WTF folder (Warcraft Text Files not WTF) upon logout. There are two types of saved variables, SavedVariables and SavedVariablesPerCharacter. They are saved on a per account and per character basis respectively. Don’t get tricked like I did, they’re nothing but global variables! You just have to add the saved variables to the toc file.

## SavedVariables: AccountDB
## SavedVariablesPerCharacter: CharacterDB

# you can use multiple variables comma delimited

In your addon you’ll usually want to initialize these the first time someone logs in with it. The PLAYER_LOGIN event (OnEnable if using Ace) is probably the best place to do this because I found some of the WoW apis aren’t ready at other times. Let’s add a login counter to demonstrate.

MyAddon = { }

local frame = CreateFrame("Frame")

-- trigger event with /reloadui or /rl
frame:RegisterEvent("PLAYER_LOGIN")

frame:SetScript("OnEvent", function(this, event, ...)
    MyAddon[event](MyAddon, ...)
end)

function MyAddon:PLAYER_LOGIN()

    self:SetDefaults()

    AccountDB.loginCount = AccountDB.loginCount + 1  
    CharacterDB.loginCount = CharacterDB.loginCount + 1

    print("You've logged in "..AccountDB.loginCount.." times")
    print(UnitName("Player").." logged in "..CharacterDB.loginCount.." times")
end

function MyAddon:SetDefaults()
    
    if not AccountDB then 

        AccountDB = {
            loginCount = 0
        }

        print("Global Initialized")
    end

    if not CharacterDB then 

        CharacterDB = {
            loginCount = 0
        }

        print("Character Initialized")
    end
end

Ace

If you’ve been reading about addons you’ve probably heard about Ace. At first I thought there was something special between WoW and Ace but nope, Ace is nothing but a 3rd party wrapper library over the WoW API. It’s designed to make some things simpler to do, and I say some because for your use case Ace might just get in the way (I ditched AceDB). Only use Ace if you really need it, some modules have a steep learning curve and it’s easy to get bogged down in the details of Ace instead of focusing on the important parts – writing your addon! In this post I’ll show how to use AceHook and AceConsole. Ace Console will be used for chat commands and also contains Ace’s Print function.

Download Ace from the site and extract the files somewhere. In your addon folder create a new folder named libs. Copy the folders LibStub, AceAddon-3.0, AceConsole-3.0, and AceHook-3.0 into libs. Next create a new file named embeds.xml in your addon’s root folder and add the following

<Ui xmlns="http://www.blizzard.com/wow/ui/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.blizzard.com/wow/ui/ ..\FrameXML\UI.xsd">
	<Script file="libs\LibStub\LibStub.lua"/>
	<Include file="libs\AceAddon-3.0\AceAddon-3.0.xml"/>
	<Include file="libs\AceConsole-3.0\AceConsole-3.0.xml"/>
	<Include file="libs\AceHook-3.0\AceHook-3.0.xml"/>
</Ui>

Now we’ll tell WoW about these libraries by adding the embeds.xml to the toc file

## Interface: 80200
## Version: 1.0.0
## Title: My Addon 
## Notes: My First Addon
## Author: You

MyAddon.lua
embeds.xml

With Ace embedded now we can aceify the lua file

--the ace way of initializing addons, add the ace modules 
--you want to use as trailing parameters in :NewAddon()
MyAddon = LibStub("AceAddon-3.0"):NewAddon("MyAddon", "AceConsole-3.0", "AceHook-3.0")

function MyAddon:OnInitialize()				

    self:SecureHook("PickupContainerItem")

    local frame = CreateFrame("Frame")
    frame:RegisterEvent("MAIL_SHOW")
    frame:RegisterEvent("AUTOFOLLOW_BEGIN")

    frame:SetScript("OnEvent", function(this, event, ...)
        MyAddon[event](MyAddon, ...)
    end)

    self:Print("Hello from Ace Console")
end

function MyAddon:OnEnable()
    --initialize Saved Variables and other start up tasks
end

function MyAddon:PickupContainerItem(container, slot)    
    _, _, _, _, _, _, link = GetContainerItemInfo(container, slot)

    self:Print(link)
end

function MyAddon:MAIL_SHOW()
    print("Mail Shown")
end

function MyAddon:AUTOFOLLOW_BEGIN(...)
    local player = ...
    print("Following "..player)
end

Now your addon is bootstrapped with Ace. What changed is how the addon is initialized and the new OnInitialize and OnEnable methods. OnInitialize can be used to register events, create hooks, and anything else you might need to do on startup.

If it all worked you should see Hello from Ace Console printed when you log in. Open the mailbox and follow random players, those should still work too.

Console Commands

To use slash commands in your addon you can use Ace Console to register commands and parse arguments.

MyAddon = LibStub("AceAddon-3.0"):NewAddon("MyAddon", "AceConsole-3.0")

function MyAddon:OnInitialize()				

    self:RegisterChatCommand("myaddon", "SlashCommands")
end

-- /myaddon 1 2 3
function MyAddon:SlashCommands(args)

    local arg1, arg2, arg3 = self:GetArgs(args, 3)	
    
    self:Print(arg1, arg2, arg3)
end

You can choose to handle arguments manually or use Ace Config, it all depends on your use case. I’d start with manual first.

UI

Sorry, I didn’t write a UI for Track Sales so I won’t be covering it. You can check out an early version of Extended Character Stats for some general ideas, visit curse for the latest. I advise you do this piece last and make sure the backend works first. Developing the UI and backend together is already hard enough no matter what environment you’re in.

Testing

The hardest part about developing an addon is testing it. Sadly, there’s no WoW sandbox or “Addon Dev Island” you can go to and have unlimited ability to test. Everything will have to be done manually in game. One nice thing is that you can call your addon’s functions any time with /run MyAddon:FunctionName(). With this it’s usually best to isolate the WoW api calls as best you can and have most of your addon’s logic in functions that you can easily test with /run. You’re also going to have to sprinkle Print statements everywhere. There’s a couple debug commands that may be useful as well. To have code changes take effect run /reloadui or /rl.

What Tripped Me Up

A couple things that weren’t immediately obvious to me was how to call functions in other files and how to reference Ace modules in other files. This is done by variables that get passed in from WoW to every lua file. You can access them by placing local addonName, ns = ... at the top of any file. addonName will be a string containing your addon name and ns acts as a namespace. This thread details it well.

To see an example add two new files MyAddonModule.lua and MyAddonHelper.lua Don’t forget to add them to the toc file!

-- MyAddon.lua

MyAddon = LibStub("AceAddon-3.0"):NewAddon("MyAddon")

function MyAddon:Test()				
    
    MyAddonModule:SayHello()
end

-- MyAddonModule.lua

MyAddonModule = MyAddon:NewModule("Module", "AceConsole-3.0")

local addonName, ns = ...

function MyAddonModule:SayHello()				

    self:Print("Hello from Module")
    ns:SayHelloHelper()
end

-- MyAddonHelper.lua

local addonName, ns = ...

function ns:SayHelloHelper()				

    print("Hello from Helper")
end

Test with /run MyAddon:Test()

With these key concepts you’ll be able to build any addon. The tricky part is figuring out which hooks and events you need. ctrl + f is going to be your best friend here, becoming familiar with the naming convention helps as well. There’s always forums like the WoW addon reddit if you have questions.

Hacking Fluent Validation: Configuring via Attributes

Fri, 09 Aug 2019 07:39:34 +0000

About a year ago I was brought on a new project to help build out the API’s. As I usually do with my API projects I added FluentValidation. It seemed like everything was going smooth until a couple developers shared they weren’t a fan of it. They didn’t like creating separate classes and wanted to use attributes instead, sigh fine. I was never a fan of attributes because I feel it makes everything too cluttered. This post is about the journey of destroying everything that’s great about FluentValidation by using attributes.

I wasn’t going to be able to use the built in DataAttributes because the classes that needed them lived in our contracts project. We wanted that dll to be dependency free so we could share it easily. Since I didn’t want to get in the business of creating a new validation framework I set out to create a set of custom attributes that could be leveraged by FluentValidation. Unknowingly, I did exactly as described in this issue. There will be a fair amount of code in this post, you can view the the final result in this gist.

Fluent Validation

If you aren’t familiar with FluentValidation, it’s a validation framework. If you hate attributes as much as I do it’s a great alternative. Validation is built from validators that you can add to the asp.net pipeline. A simple example is

public class PersonValidator : AbstractValidator<Person>
{
    public PersonValidator()
    {
        RuleFor(x => x.Name).NotEmpty();
    }
}

Warning

Before doing something like this, it’s important to note that it’s potentially very dangerous. You can get into trouble by leveraging the internals of the library and using it in ways the authors never intended. You can say goodbye to semantic versioning since that only covers the public API. Which means even a bump in a minor or patch version (which are backwards compatible by definition) could break your custom code. If you can’t incorporate the new changes for whatever reason you won’t be able to upgrade. You may also burn hours with other oddities that appear more silently. This all has to be taken into account before you go 1337 hacker. With that in mind, considering the internal surface area that I’ll be touching is relatively small, along with the fact FV is a mature library with less risk of major breaking changes, I was confident going forward with this (famous last words).

The plan

The ultimate goal is to configure FluentValidation with attributes and not use the AbstractValidator<T> classes.

don’t reinvent the wheel, leverage fluent validation (version 8.1.3), look at internal pieces if needed
map our custom attributes to FV parlance (RequiredAttribute => NotEmpty)
inject instances of IValidator<T> to the IoC container, FV by design requires these implementations
build these instances dynamically, the types will be unknown at compile time

Using the example from earlier, my first thought was I could call the RuleFor(x => x.Name).NotEmpty() methods using reflection. At the time it sounded like a good idea and the most simple way, though I knew it would also be the ugliest (spoiler: awful idea). Well, I was having trouble making it work even with hardcoded types, had doubts I’d even be able to make it work without the hardcodes, the code was super ugly, and not to mention I’m calling 3rd party library code through reflection…not a good idea. While I was spinning my tires on this piece, I realized I didn’t have to actually call these methods at all! I only have to mimic their behavior and I can do that by whatever means.

Opening up FluentValidation

I opened up fluent validation and started debugging through a simple test from this class. I tried not to fall into the common tendency of trying to learn EVERYTHING, that’s just impossible in any reasonable amount of time and unnecessary. After stepping through the code for a bit I found FV to be a great codebase, everything was very intuitive and it was easy to see what was going on.

Eventually I found a key piece in Rule.AddValidator(validator). I saw I just need to add a validator to a rule. Next I had to find out what a PropertyRule is and how they are used.

I learned that the PropertyRule is the essential piece in validating objects. If my assumption is correct then according to that line of a code all I have to do is create a PropertyRule and add IPropertyValidator's for the different validations (required, max length, etc). It’s turning out to be a lot simpler than I first thought. To prove that assumption I wrote a test to see if the PropertyRule produced the behavior I expected…a validated object with a friendly error message.

public void should_validate_type()
{
   // Create the property rule and add the validator as FluentValidation does internally
   var rule = PropertyRule.Create<Person, string>(x => x.Name);
   rule.AddValidator(new NotEmptyValidator(defaultValueForType: null));
   
   var instanceToValidate = new Person { Name = null };

   var results = rule.Validate(new ValidationContext(instanceToValidate));

   results.Select(x => x.ErrorMessage)
          .SingleOrDefault()
          .ShouldBe("'Name' must not be empty.");
}

Perfect! The test passed and I know I’m on the right track. I tried to take a very methodical approach, all hard codes to start. If you begin trying to do things dynamically first it makes the task that much harder. If you can’t get something to work with hardcodes how are you going to be able to make it work dynamically? I wanted to make it work first and prove the concept. Now that I know this works, I have a clear path forward to make it dynamic. Dynamic meaning I won’t be writing code like PropertyRule.Create<Person, string>(x => x.Name). At compile time the types will be unknown, so I won’t be able to strongly type the generic parameters and lambda expression.

Dynamic Property Rule

The next goal is to create a PropertyRule dynamically. I’ll save “dynamic validators” for later. I have to figure out how to call the factory method PropertyRule.Create and pass a lambda expression to it. I could call into PropertyRule.Create but the implementation is simple enough I can add my own factory method named CreateRule.

The one I added has the same exact signature PropertyRule CreateRule<TInstance, TProperty>(Expression<Func<TInstance, TProperty>> expression), though the implementation is slightly different. Calling PropertyRule.CreateRule<TInstance, TProperty>() is easy enough with the MakeGenericMethod api but the hard part is going to be the lambda expression x => x.Name. I’ll have to hand roll expression trees.

To do that you can use the expression api. If you’re unfamiliar with expressions and compiled expressions it’s a complex but powerful language feature. Essentially, you can create code dynamically and execute it as if it were handwritten. There’s a slight performance hit but it can be much faster than reflection. Many libraries like NServiceBus and AutoMapper use compiled expression trees.

After some googling and trial and error I successfully created an instance of PropertyRule along with the expression parameter dynamically. This was single handedly the hardest part. The test is now

public void should_validate_type()
{
   var instanceType = typeof(Person);
   var propertyType = typeof(string);
   var propertyFunc = typeof(Func<,>).MakeGenericType(instanceType, propertyType);

   var instance = Expression.Parameter(instanceType, "x");
   var property = Expression.Property(instance, propertyName: "Name");
   var expression = Expression.Lambda(propertyFunc, property, instance);

   // The dynamic version of PropertyRule.Create<Person, string>(x => x.Name)
   var rule = (PropertyRule)typeof(FluentValidationTests)
                            .GetMethod(nameof(CreateRule))
                            .MakeGenericMethod(instanceType, propertyType)
                            .Invoke(null, new object[] { expression });

   rule.AddValidator(new NotEmptyValidator(defaultValueForType: null));
   
   var instanceToValidate = new Person();
   
   var results = rule.Validate(new ValidationContext(instanceToValidate));

   results.Select(x => x.ErrorMessage)
          .SingleOrDefault()
          .ShouldBe("'Name' must not be empty.");
}

Custom Attributes

With the rule being created dynamically I now needed a way of mapping my custom attributes to an IPropertyValidator from FluentValidation. What I came up with are these couple classes.

[AttributeUsage(AttributeTargets.Property)]
public abstract class ValidationAttribute : Attribute 
{

}

public class Required : ValidationAttribute 
{

}


public interface AttributeValidator
{
   bool Matches(ValidationAttribute attribute);
   IPropertyValidator GetValidator(PropertyInfo property, ValidationAttribute attribute);
}

public abstract class AttributeValidator<T> : AttributeValidator where T : ValidationAttribute
{
   public bool Matches(ValidationAttribute attr) => typeof(T) == attr.GetType();

   public IPropertyValidator GetValidator(PropertyInfo property, ValidationAttribute attribute)
   {
       return GetValidator(property, (T)attribute);
   }

   // This will do the mapping from ValidationAttribute to IPropertyValidator
   protected abstract IPropertyValidator GetValidator(PropertyInfo property, T attribute);
}

This Matches => DoSomething concept is commonly seen in the Strategy pattern. I first came across this way of implementing the pattern after reading how FubuMVC uses strongly typed config classes (now comes ootb in asp.net core). With these pieces ValidationAttributes can automatically be added without having to change existing code. Once you add a new ValidationAttribute and AttributeValidator<T> everything will just work.

If you’re interested about the strategy pattern, other implementations can be found in HtmlTags, AutoMapper, and my not abandoned library Construktion (as a chain of responsibility).

Implementations of AttributeValidator<T> look like

public class RequiredValidator : AttributeValidator<Required>
{
    protected override IPropertyValidator GetValidator(PropertyInfo property, Required attribute)
    {
        var defaultValue = property.PropertyType.IsValueType
                       ? Activator.CreateInstance(property.PropertyType)
                       : null;

        return new NotEmptyValidator(defaultValue);
    }
}

public class MaxLengthValidator : AttributeValidator<MaxLength>
{
    protected override IPropertyValidator GetValidator(PropertyInfo property, MaxLength attribute)
    {
        return new MaximumLengthValidator(attribute.MaxLength);
    }
}

Next I need some orchestration class (which is a glorified static class in this case) to handle the strategies. This class handles the mapping of an AttributeValidator to a FluentValidation IPropertyValidator and adds it to the PropertyRule. The interface AttributeValidator is used as a crutch to make referencing the open the generic easier.

public static class ValidatorExtensions
{
  private static readonly List<AttributeValidator> _attributeValidators = typeof(AttributeValidator)
      .Assembly
      .GetTypes()
      .Where(x => typeof(AttributeValidator).IsAssignableFrom(x) && !x.IsAbstract)
      .Select(Activator.CreateInstance)
      .Cast<AttributeValidator>()
      .ToList();

 public static void AddValidator(this PropertyRule rule, PropertyInfo property, ValidationAttribute attribute)
 {
     var attributeValidator = _attributeValidators.SingleOrDefault(x => x.Matches(attribute)) ??
                    throw new Exception(
                       $"Could not find a validator for attribute {attribute.GetType()}. " +
                       $"Please add an implementation of AttributeValidator<{attribute.GetType()}>");
            
     var propertyValidator = attributeValidator.GetValidator(property, attribute);

     rule.AddValidator(propertyValidator);
 }
}

Now I just need to add a RequiredAttribute to the Name property on my class. The unit test has to grab all the ValidationAttributes on a property and add their corresponding validator.

public void should_validate_type()
{
   var rule = // Created Dynamically
   
   var propertyInfo = typeof(Person).GetProperty("Name");

   var validationAttributes = propertyInfo
                              .GetCustomAttributes(typeof(ValidationAttribute), true)
                              .Cast<ValidationAttribute>()
                              .ToList();

   // Leverage the "orchestrator"
   foreach(var attribute in validationAttributes)
       rule.AddValidator(propertyInfo, attribute)
   
   var instanceToValidate = new Person();

   var results = rule.Validate(new ValidationContext(instanceToValidate));

   results.Select(x => x.ErrorMessage)
          .SingleOrDefault()
          .ShouldBe("'Name' must not be empty.");
}

The last thing left to do is create dynamic instances of IValidator<T> to inject into the container. I’ll need a marker class to build instances from and my initial thought was public class CustomValidator<T> : AbstractValidator<T> { } But how am I going to add the PropertyRules? The base AbstractValidator<T> expects the rules to be added through the DSL, not manually like this. It seemed like I was stuck and I went off the rails a little. I chose to implement the interface IValidator<T> instead of leveraging AbstractValidator<T>. I basically copy and pasted the whole AbstractValidator<T> into my custom implementation. It worked but it was pretty annoying that I had to do that, it wasn’t until a 2nd pass (which was the writing of this post) that I realized AbstractValidator<T> has an AddRule method, doh!

After that epiphany the custom implementation was removed and the CustomValidator class became.

public class CustomValidator<T> : AbstractValidator<T>
{
     public CustomValidator(IEnumerable<PropertyRule> rules)
     {
         foreach (var rule in rules)
             AddRule(rule);
     }
}

Now the final unit test is

public void should_validate_type()
{
   var rule = // Created Dynamically
   
   // Add validators to rule

   // Create the validator dynamically
   var customValidator = typeof(CustomValidator<>).MakeGenericType(instanceType);
   var validator = (IValidator)Activator.CreateInstance(customValidator, new List<PropertyRule> { rule });
   var instanceToValidate = new Person();

   var result = validator.Validate(instanceToValidate);

   result.Errors
          .Select(x => x.ErrorMessage)
          .SingleOrDefault()
          .ShouldBe("'Name' must not be empty.");
} 

This proves the whole concept now! I was able to successfully create an IValidator<T> with the only input being attributes on a property. All that’s left is to add the CustomValidator<T> to the IoC container, structuremap in this case.

As I said in the beginning it’s generally a bad idea to bypass the public api of 3rd party libraries. Only hack libraries like this after you’ve explored all other options and considered the potential consequences. This was a fun project and a lesson learned why as a library author you should think about making more of your types public instead of internal. If these types were internal I’d never be able to extend it in this way.

Complete gist