Showpitch Advanced Part 3: Using Neat Architecture for Validation

Last week we reviewed using Neat Architecture for Showpitch‘s Logging. This week we’re going to go in to Neat and Validation on Showpitch.

We’re all familiar with the need for Validation when building an application. Maybe there’s a property that should be an email, or maybe there’s an integer that should always be below a certain amount. In any given application there’s going to be a lot of these Validation concerns that come up. And just as with Logging we’re going to end up writing a lot of the same code, over and over again, unless there’s a better way.

Validation, Over and Over

Lets look at a typical Validation scenario:

public class Thing
{
    public string ThingAMaJig { get; set; }
    public int ThingAMaBob { get; set; }
}

public class AThingAddingClass : IAThingAddingClass
{
    private readonly IThingRepository _thingRepository;
    
    public AThingAddingClass(IThingRepository thingRespository)
    {
        _thingRepository = thingRepository;
    }
    
    public void AddANewThing(Thing aThing)
    {
        if(aThing.ThingAMaJig == null)
        {
            throw new ValidationException("ThingAMaJig Required!");
        }
        _thingRepository.Save(aThing);
    }
}

That’s really simple, but now imagine writing this out each time you’re going to do anything with that Thing, and then extrapolate that out to hundreds of times in every application, for all of the properties you’re going to validate! Consider:

public class AThingAddingClass : IAThingAddingClass
{
    private readonly IThingRepository _thingRepository;
    
    public AThingAddingClass(IThingRepository thingRespository)
    {
        _thingRepository = thingRepository;
    }
    
    public void AddANewThing(Thing aThing)
    {
        if(aThing.ThingAMaJig == null)
        {
            throw new ValidationException("ThingAMaJig Required!");
        }
        _thingRepository.Save(aThing);
    }
    
    public void UpdateAThing(Thing aThing)
    {
        if(aThing.ThingAMaJig == null)
        {
            throw new ValidationException("ThingAMaJig Required!");
        }
        _thingRepository.Update(aThing);
    }
    
    public void IndexAThing(Thing aThing)
    {
        if(aThing.ThingAMaJig == null)
        {
            throw new ValidationException("ThingAMaJig Required!");
        }
        _thingRepository.Index(aThing);
    }
    
    public void DefaultAThing(Thing aThing)
    {
        if(aThing.ThingAMaJig == null)
        {
            throw new ValidationException("ThingAMaJig Required!");
        }
        aThing.ThingAMaBob = 7;
        _thingRepository.Save(aThing);
    }
}

Things are already starting to get out of hand!

Validation, A Validator For Every Object

So we can start to address this issue with a new object, specifically one that validates that Thing for us:

public class AThingValidatingClass : IAThingValidatingClass
{
    public void ValidateAThing(Thing aThing)
    {
        if(aThing.ThingAMaJig == null)
        {
            throw new ValidationException("ThingAMaJig Required!");
        }
    }
}

Let’s try using this in the previous out of control example:

public class AThingAddingClass : IAThingAddingClass
{
    private readonly IThingRepository _thingRepository;
    private readonly IAThingValidatingClass _aThingValidatingClass;
    
    public AThingAddingClass(IThingRepository thingRespository, IAThingValidatingClass aThingValidatingClass)
    {
        _thingRepository = thingRepository;
        _aThingValidatingClass = aThingValidatingClass;
    }
    
    public void AddANewThing(Thing aThing)
    {
        _aThingValidatingClass.ValidateAThing(aThing);
        _thingRepository.Save(aThing);
    }
    
    public void UpdateAThing(Thing aThing)
    {
        _aThingValidatingClass.ValidateAThing(aThing);
        _thingRepository.Update(aThing);
    }
    
    public void IndexAThing(Thing aThing)
    {
        _aThingValidatingClass.ValidateAThing(aThing);
        _thingRepository.Index(aThing);
    }
    
    public void DefaultAThing(Thing aThing)
    {
        _aThingValidatingClass.ValidateAThing(aThing);
        aThing.ThingAMaBob = 7;
        _thingRepository.Save(aThing);
    }
}

Well that certainly shortens things up. But we still have a couple of issues here. First, we’d now have to develop a Validator for every object we want to Validate. Second, we seem to have more than one responsibility in our methods now. Before our methods just did something with a Thing, but now they validate a Thing and then do something with it.

Validation, A Validator and a Decorator For Every Object Then

So lets address the second issue first. We could separate the responsibilities, just like with Logging, using a Decorator:

public class AThingAddingClass : IAThingAddingClass
{
    private readonly IThingRepository _thingRepository;
    
    public AThingAddingClass(IThingRepository thingRespository)
    {
        _thingRepository = thingRepository;
    }
    
    public void AddANewThing(Thing aThing)
    {
        _thingRepository.Save(aThing);
    }
    
    public void UpdateAThing(Thing aThing)
    {
        _thingRepository.Update(aThing);
    }
    
    public void IndexAThing(Thing aThing)
    {
        _thingRepository.Index(aThing);
    }
    
    public void DefaultAThing(Thing aThing)
    {
        aThing.ThingAMaBob = 7;
        _thingRepository.Save(aThing);
    }
}

public class AThingAddingClassValidationDecorator : IAThingAddingClass
{
    private readonly IAThingAddingClass _aThingAddingClass;
    private readonly IAThingValidatingClass _aThingValidatingClass;
    
    public AThingAddingClass(IAThingAddingClass aThingAddingClass, IAThingValidatingClass aThingValidatingClass)
    {
        _aThingAddingClass = aThingAddingClass;
        _aThingValidatingClass = aThingValidatingClass;
    }
    
    public void AddANewThing(Thing aThing)
    {
        _aThingValidatingClass.ValidateAThing(aThing);
        _aThingAddingClass.AddANewThing(aThing);
    }
    
    public void UpdateAThing(Thing aThing)
    {
        _aThingValidatingClass.ValidateAThing(aThing);
        _aThingAddingClass.UpdateAThing(aThing);
    }
    
    public void IndexAThing(Thing aThing)
    {
        _aThingValidatingClass.ValidateAThing(aThing);
        _aThingAddingClass.IndexAThing(aThing);
    }
    
    public void DefaultAThing(Thing aThing)
    {
        _aThingValidatingClass.ValidateAThing(aThing);
        aThing.ThingAMaBob = 7;
        _aThingAddingClass.DefaultAThing(aThing);
    }
}

So now we only have one responsibility per method, but we still have the issue of having to build a Validator for each object. And on top of that, now we have to build a Decorator for each object as well!

Validation, A Better Way

Just as when we reviewed Logging, we know there’s a better way using interceptors. But how can we build something so generic for Validation?

Luckily for us, .Net has had a solution available for quite a while in the form of System.ComponentModel.DataAnnotations. These have been used in ASP.Net MVC for quite a while, but we can leverage them to build a Validation interceptor in to Neat, and we have!

Using System.ComponentModel.DataAnnotations we can declare how to Validate each property right on that property! So now our Thing becomes:

using System.ComponentModel.DataAnnotations;

public class Thing
{
    [Required]
    public string ThingAMaJig { get; set; }
    public int ThingAMaBob { get; set; }
}

From here, our Validation interceptor can pick up any of a large number of System.ComponentModel.DataAnnotations and Validate the value in the property based on them. We’ve built the rest of that in to the ApplicationProcessing interceptor in Neat, by way of an ApplicationProcessingRule for Validation. You can take a look at the objects that leverage this for yourself in Neat:

  • Neat.Infrastructure.Unity.Interceptor.ApplicationProcessingInterceptor
  • Neat.Infrastructure.Unity.ApplicationProcessing.ApplicationProcessor
  • Neat.Infrastructure.Unity.ApplicationProcessing.IApplicationProcessingRule
  • Neat.Infrastructure.Validation.ApplicationProcessing.ValidationApplicationProcessingRule
  • Neat.Model.NeatExample

This leaves us with a much simpler and more concise class than any of the other options, without having to build a Decorator ourselves:

public class AThingAddingClass : IAThingAddingClass
{
    private readonly IThingRepository _thingRepository;
    
    public AThingAddingClass(IThingRepository thingRespository)
    {
        _thingRepository = thingRepository;
    }
    
    public void AddANewThing(Thing aThing)
    {
        _thingRepository.Save(aThing);
    }
    
    public void UpdateAThing(Thing aThing)
    {
        _thingRepository.Update(aThing);
    }
    
    public void IndexAThing(Thing aThing)
    {
        _thingRepository.Index(aThing);
    }
    
    public void DefaultAThing(Thing aThing)
    {
        aThing.ThingAMaBob = 7;
        _thingRepository.Save(aThing);
    }
}

But how do you implement the System.ComponentModel.DataAnnotations for Validation? Lets look at an example:

public class ValidationResponse
{
    public ValidationResponse()
    {
        ValidationErrors = new List();
        IsValid = true;
    }
    
    public bool IsValid { get; set; }
    public List ValidationErrors { get; set; }
    
}

// SNIP!
private ValidationResponse Validate(object objectToValidate)
{
    var validationResponse = new ValidationResponse();
    var results = new List();
    if (!Validator.TryValidateObject(objectToValidate, new System.ComponentModel.DataAnnotations.ValidationContext(objectToValidate), results, true))
    {
        validationResponse.IsValid = false;
        validationResponse.ValidationErrors.AddRange(results.Select(validationResult => validationResult.ErrorMessage));
    }
    
    return validationResponse;
}
// SNIP!

That’s it!

Validation can quickly become a lot of work in an application, but by using Neat, especially the Validation interceptor and System.ComponentModel.DataAnnotations Validation can be added in to an application quickly and easily. We’ve used this Validation at Showpitch to very quickly spin up new Domain Objects and make them available for use while protecting the data from invalid inputs and states. It has saved and will continue to save hours of work for Showpitch!

Would you like to know more about something I’ve written about, or do you want to see me cover something in the next post? Are there parts of Neat or Showpitch you’d like to learn more about? Please comment below! And check back for more!

<< Back to Showpitch Advanced Part 2

Advertisements

Showpitch Advanced Part 2: Using Neat Architecture for Logging

Last week we reviewed using Neat Architecture for Showpitch‘s Domain Services. This week we’re going to go in to Neat and Logging on Showpitch.

At Showpitch we’ve built on the Logging Interceptor that’s offered in Neat. But it’s a fantastic starting point! Using this we get a lot of functionality right out of the box for each new piece of code we add to Showpitch. So let’s talk about Logging and how Neat Logging solves some pretty common problems!

Logging, A Necessary Evil

As app developers, we all eventually reach the same conclusion, one famously posited by Murphy

If something can go wrong, it eventually will go wrong.

In the face of the inevitable we then have to acknowledge that we will need to understand what’s going wrong, when, and how. And so we start adding Logging code to our app.

So why do I call Logging a “Necessary Evil”?

This is because, as app developers, we are not writing apps for Logging. We’re not designing, coding, and hacking for the sake of Logging. We build apps to solve problems. If we didn’t need to write code, reserve systems resources, and spend database and disk space for Logging we wouldn’t. And yet time and again we spend hours of our time, countless CPU cycles, and endless bytes of storage on Logging.

So great is the tax that is levied by Logging that it could easily be framed as an app’s equivalent of that dastardly Sheriff of Nottingham. We hate to pay its tax, but there’s no getting out of it.

And without Logging we can’t know what’s going wrong, when, and how. It’s Evil, but it’s Necessary, hence a “Necessary Evil”.

Logging, A Cross Cutting Concern

Once we accept the need for Logging, the next step is to add it to our app. And this is where, for many app developers, the pain begins. How familiar does this code block look to you?

public class AThingDoingClass : IAThingDoingClass
{
    public void DoesOneThingAndOneThingOnly()
    {
        try
        {
            DoSomethingThatCouldThrowAnError();
        }
        catch(Exception ex)
        {
            Logger.Log(ex);
        }
    }
}

What can we learn from this example?

First, we’re using 8 lines of code, for something that should only require 1. That’s a lot of extra code, just to accommodate Logging.

Second, we can probably expect to see this code duplicated about 500 times in our application. Not very DRY, is it? We need Logging all over the place, but we’re reproducing the same code over and over!

Finally, let’s talk SOLID, specifically Single Responsibility. Where does our method say it’s a Logging method? It “Does One Thing And One Thing Only” from what we can see. It would seem this method doesn’t live up to its Single Responsibility.

This is where such a Cross Cutting Concern comes from. All over the app we’re going to need Logging, but this concern isn’t specific to any given method, nor is it the responsibility of any of those methods. And yet it shows up all over!

Logging, A Decorator Approach

So could we at least address the Single Responsibility issue?

Yes, by introducing a Decorator we can separate these responsibilities. For example:

public class AThingDoingClass : IAThingDoingClass
{
    public void DoesOneThingAndOneThingOnly()
    {
        DoSomethingThatCouldThrowAnError();
    }
}

public class AThingDoingClassLoggingDecorator : IAThingDoingClass
{
    private read only IAThingDoingClass _aThingDoingClass;
    
    public AThingDoingClassLoggingDecorator(IAThingDoingClass aThingDoingClass)
    {
        _aThingDoingClass = aThingDoingClass;
    }
    public void DoesOneThingAndOneThingOnly()
    {
        try
        {
            _aThingDoingClass.DoesOneThingAndOneThingOnly();
        }
        catch(Exception ex)
        {
            Logger.Log(ex);
        }
    }
}

Ok, now we only have one responsibility per method. Great, but this is still a lot of code to write! And it’s still not DRY! So is there an even better way?

Logging, An Aspect and Neat

What if there were a way to wrap every class and every method in your application with one of these Decorators, automatically, without having to repeat the same code all over?

That’s what Neat does! Using Interceptors built in to Microsoft Practices Unity 3 we’ve built a Logging Interceptor in Neat, which does exactly this.

This is evocative of Aspect-Oriented Programming (AOP). .Net doesn’t lend itself well to AOP, but using Interceptors we can achieve something very close to it! And this is exciting, because it means we can now assign behavior in our app simply by ascribing an Aspect to our code! And once we have that, we can make these Aspects a convention of our code. This gets us a lot of behavior for a much smaller investment!

We even built a Decorator around the Microsoft Practices Unity 3 container that automatically registers this Interceptor with every class registration. This makes the Logging Aspect of our app a convention that every class and every method uses. We’ve also included a Mongo Logging Provider, built on top of nLog, that’s already wired up in the Neat example solution. This way you get Logging right away, no muss, no fuss!

So what does this mean for a developer? It means you can simplify and reduce code, like the example code, to only what it does, and let the Architecture take care of Logging for you. For example:

public class AThingDoingClass : IAThingDoingClass
{
    public void DoesOneThingAndOneThingOnly()
    {
        DoSomethingThatCouldThrowAnError();
    }
}

That’s it! The Logging is there, but it’s intrinsic to the app now.

If you want to explore how this has been done, take a look under the hood in the Neat example solution. Get started at the GitHub Page for Neat.

The following objects comprise this Logging solution in Neat and will be interesting to look at:

  • Neat.Infrastructure.Unity.Interceptor.LoggingInterceptor
  • Neat.Infrastructure.Unity.LoggingUnityContainer
  • Neat.Infrastructure.Logging.ILogProvider
  • Neat.Infrastructure.Logging.NLogProvider

If you want to build a new LogProvider to use a different Logging system, or even a custom Logging system, then just build a new class that implements Neat.Infrastructure.Logging.ILogProvider and register it with the container. Your Logging system will now be used!

That’s Logging in Neat! Showpitch started with this solution and with it and its evolution, we’ve saved our team literally hundreds of hours of Production troubleshooting and writing and maintaining Logging code for our platform!

Is there something you want to see me cover in the next post? Is there a part of Neat or Showpitch you want to see more on, or something you want to see added to Neat? Please add a comment below! And keep checking back to learn more!

<< Back to Showpitch Advanced Part 1
On to Showpitch Advanced Part 3 >>

Showpitch Advanced Part 1: Using Neat Architecture for Domain Services

After 3 weeks of high level review of Showpitch we’re going to dive in to more advanced topics. This week we’re going to cover the specifics of using Neat Architecture for Showpitch.

Neat Architecture

Showpitch uses the Neat Architecture to allow for very rapid development and a great amount of flexibility and power. You can find the Neat Architecture in practice on GitHub, so check it out when you have a chance! Now let’s get in to what Neat Architecture is.

Neat Components

Neat starts with several important components, all from NuGet:

  • ASP.Net Web Api
    • Microsoft.AspNet.Cors.5.2.3
    • Microsoft.AspNet.WebApi.5.2.3
    • Microsoft.AspNet.WebApi.Client.5.2.3
    • Microsoft.AspNet.WebApi.Core.5.2.3
    • Microsoft.AspNet.WebApi.Cors.5.2.3
    • Microsoft.AspNet.WebApi.Tracing.5.2.3
    • Microsoft.AspNet.WebApi.WebHost.5.2.3
  • Microsoft Practices Unity 3
    • CommonServiceLocator.1.3
    • Unity.3.5.1404.0
    • Unity.Interception.3.5.1404.0
    • Unity.WebAPI.5.1
  • OData
    • Microsoft.AspNet.WebApi.OData.5.5.1
    • Microsoft.Data.Edm.5.6.0
    • Microsoft.Data.OData.5.6.0
    • System.Spatial.5.6.0
  • NLog
    • NLog.4.0.1
    • NLog.MongoDB.0.7.0
    • mongocsharpdriver.1.8.3
  • JSON.Net
    • Newtonsoft.Json.6.0.4
    • Newtonsoft.Json.7.0.1
  • Octopack
    • OctoPack.3.0.42
  • MongoRepository
    • MongoRepository.1.6.8
    • mongocsharpdriver.1.10.0

Neat Solution Structure

The Solution Structure is comprised of a pretty traditional N-Tier stack. This stack is broken out in to a few more layers to facilitate further decoupling and reduce friction among components.

  • Neat.Model – All Domain Models
  • Neat.Data – Common Data Access Definition
  • Neat.Data.Mongo – Mongo Data Access Implementation
  • Neat.Infrastructure – Components for Application Functionality
  • Neat.Application – Core Business Logic
  • Neat.Service – Orchestration of Business Logic Components
  • Neat.Infrastructure.WebApi – Web Api Specific Functional Components
  • Neat.Web.Api – Web Api Host

A Closer Look at Unity and IoC in Neat

In Neat we use a class called Bootstrapper in each project to configure all Type Registrations for that project. We then expose an Attach method in each Bootstrapper, allowing components that rely on that project to run that project’s configuration against that component’s Unity container. Here’s an example:

public static class Bootstrapper
{
    public static void Register()
    {
        var container = new UnityContainer();

        Register(container);
    }

    public static void Attach(IUnityContainer container)
    {
        Register(container);
    }

    private static void Register(IUnityContainer container)
    {
        Neat.Data.Mongo.Bootstrapper.Attach(container);
        Neat.Infrastructure.Bootstrapper.Attach(container);

        container.RegisterType(typeof (IDomainApplication<>),
            typeof (DomainApplication<>),
            new ContainerControlledLifetimeManager());

        container.RegisterAllService<IApplication>();
    }
}

There’s a lot happening in this code:

  • The Attach Method – Components that depend on this one pass their container in here so that this component can register its classes on the same container
  • The Two Attach Calls – This component in turn calls Attach on the components it depends on
  • The typeof Registrations – This is how to register the generic implementation so that any type passed to the generic results in a resolvable type. Using this registration pattern throughout the stack these components can handle any domain object from the Web Api through to the Database
  • RegisterAllService – This is an Unity Extension in Neat that registers every class as the default registration for its other interfaces when it has the marker interface specified
  • ContainerControlledLifetimeManager – This lifetime manager ensures that the type registered is resolved as a Singleton

A Closer Look at the Web Api Controller in Neat

The Controllers in Neat use the generic Domain stack to expose the Domain Models. Here’s an example:

public class NeatController : BaseReadWriteDeleteController<NeatExample>
{
    public NeatController(IDomainService<NeatExample> domainService)
        : base(domainService)
    {}
}

As you can see, using the Unity registration from before and this Controller pattern, we’re able to rapidly expose Api Services for new Domain Models. But where are the methods? The answer lies in the BaseReadWriteDeleteController:

public class BaseReadWriteDeleteController<T> : BaseApiController where T : class, IEntity<string>, new()
{
    private readonly IDomainService<T> _domainService;

    public BaseReadWriteDeleteController(IDomainService<T> domainService)
    {
        _domainService = domainService;
    }

    // GET api/{T}
    [EnableQuery]
    public IQueryable<T> Get()
    {
        return _domainService.GetAll();
    }

    // GET api/{T}/{id}
    public T Get(string id)
    {
        return _domainService.GetById(id);
    }

    // POST api/{T}
    public void Post([FromBody]T entity)
    {
        _domainService.Add(entity);
    }

    // PUT api/{T}
    public void Put([FromBody]T entity)
    {
        _domainService.Update(entity);
    }

    // DELETE api/{T}/{id}
    public void Delete(string id)
    {
        _domainService.Delete(id);
    }

    // GET api/{T}/getempty
    [HttpGet]
    public T GetEmpty()
    {
        return new T();
    }
}

This pattern works very well with MongoRepository due to its generic implementation. Perhaps in a future post we’ll cover an Entity Framework Code First approach for this.

This architecture allows for very rapid application development. To add a new Domain Service to this stack the steps are simply:

  1. Add a new Domain Model
  2. Add a new Controller and inherit from the appropriate Base Controller with the right methods
  3. Profit!

In future posts we’ll cover how to add additional behavioral capabilities in to this architecture and extend it with other service features. Is there a specific part of this architecture that you have questions about? Is there another part of Neat you saw on GitHub that you want me to write about next? Please leave a comment below to let me know! And keep checking back for more info about Showpitch and Neat!

<< Back to Showpitch 103
On to Showpitch Advanced Part 2 >>

Announcing Neat!

This week I want to talk about an Open Source project I’ve launched called Neat! When I say Open Source, I mean that this project is licensed under the MIT License, you can read this license in the LICENSE.txt file included with the project, or at the following URL – http://opensource.org/licenses/MIT

This project will contain many handy little infrastructure things that come in handy when working with .Net.

So far I’ve added a RESTful client object that greatly simplifies the work of calling and using responses from RESTful services. You’ll find this under the Neat.Service.Client.Rest namespace. I’ve also added some wrappers, generated using the technique covered last week, of some of the .Net components needed for the framework components that have been added. These are in the Neat.Wrapper namespace.

You can find the code for this project on GitHub at https://github.com/johnbrunnings/Neat. Contact me at me@johnbrunnings.com if you’d like to contribute.

Planned for this framework are the following features –

    • Encryption
      • SHA-512
      • MD5
      • AES (Rijndael)
    • Unity
      • Lifetime Handlers
        • WebContext
        • ServiceContext
    • Aspects
      • Logging
      • Performance
      • Feature Flag
      • Exception Handling
    • ServiceHosts & Factories (WCF)
    • Controller Factories
      • MVC 4
    • Random String Generation
    • Configuration Management
      • MsNetAppSettingsXml
      • MsNetCustomSettingsXml
      • MsNetConnectionStringsXml

Please contact me if you’d like to suggest anything as well.