Forem: Jimmy

Adding Revision Support to Entities in Entity Framework Core

Jimmy — Wed, 13 Nov 2024 09:57:45 +0000

Introduction

As applications evolve, the need to track historical data or version control often arises. In this article, we’ll refactor an existing entity to support revisions using Entity Framework Core, allowing us to maintain a history of changes without duplicating the data model or introducing unnecessary complexity.

We’ll walk through a step-by-step approach to transition a simple Document entity into a revisioned model. This method uses a discriminator to track multiple versions of the same document, with all revisions stored in the same database table. This approach is both flexible and scalable, making it easy to apply to other entities in your system.

Prerequisites

This guide assumes a basic understanding of Entity Framework Core and uses the following NuGet packages:

Microsoft.EntityFrameworkCore (8.0.8)
Microsoft.EntityFrameworkCore.Relational (8.0.8)

Step 1: Defining the Initial `Document` Entity

Let’s begin with a simple Document entity representing a file or resource stored in the system. This basic setup works fine for many use cases but falls short when historical tracking or version control is needed.

public class Document
{
    public Guid Id { get; set; }
    public string Name { get; set; }
    public string Content { get; set; }
}

This model currently tracks only the latest state of a document. To introduce revisioning, we’ll need to refactor this structure.

Step 2: Refactoring to Support Revisions

To enable revisioning, we will introduce a base class DocumentBase that holds shared properties and split the Document entity into two types: one representing the current state and another representing historical revisions.

Updated Entities

public abstract class DocumentBase
{
    public Guid Id { get; set; }
    public string Name { get; set; }
    public string Content { get; set; }
}

public class Document : DocumentBase
{
    // Represents the latest version of the document.
}

public class DocumentRevision : DocumentBase
{
    // Represents an older version (revision) of the document.
}

With this setup, both the current document and its revisions share the same table structure, but they are logically distinct entities.

Step 3: Configuring the Discriminator in Entity Framework Core

Now, we need to configure Entity Framework Core to manage these two types (Document and DocumentRevision) in the same database table. This is done using a discriminator column that tells Entity Framework Core which rows represent revisions.

public class Context : DbContext
{
    protected override void OnModelCreating(ModelBuilder modelBuilder)
    {
        modelBuilder.Entity<DocumentBase>(builder =>
        {
            builder.ToTable("Documents");
            builder.HasKey(x => x.Id);

            builder.HasDiscriminator<bool>("IsRevision")
                .HasValue<Document>(false)
                .HasValue<DocumentRevision>(true);
        });
    }
}

Here, we’ve defined an internal IsRevision column that will indicate whether a row is a Document or a DocumentRevision. This allows us to store both types in the same Documents table.

Step 4: Establishing the Document-Revision Relationship

A Document can have multiple revisions. We’ll establish a one-to-many relationship between the Document and its DocumentRevisions.

Entity Relationship

public class Document : DocumentBase
{
    private List<DocumentRevision>? _revisions;

    public List<DocumentRevision> Revisions
    {
        get => _revisions ??= new List<DocumentRevision>();
        set => _revisions = value;
    }
}

public class DocumentRevision : DocumentBase
{
    public Guid DocumentId { get; set; }
    public Document Document { get; set; }
}

Configuring the Relationship in `DbContext`

modelBuilder.Entity<Document>()
            .HasMany(d => d.Revisions)
            .WithOne(r => r.Document)
            .OnDelete(DeleteBehavior.Restrict);

The DeleteBehavior.Restrict enforces that revisions must be deleted before the document itself can be removed, ensuring no orphaned DocumentRevisions. Alternatively, you could use DeleteBehavior.NoAction, which allows orphaned revisions (in which case, DocumentId must be nullable).

Step 5: Encapsulating Revision Creation

To ensure clean design, it’s important to encapsulate revision creation within the Document class. This prevents revisions from being manually created elsewhere, reducing the risk of inconsistent data.

public class Document : DocumentBase
{
    public void CreateRevision()
    {
        Revisions.Add(new DocumentRevision(this));
    }
}

Additionally, by making the DocumentRevision constructor internal, we enforce that only Document can create revisions:

public class DocumentRevision : DocumentBase
{
    internal DocumentRevision(Document document)
    {
        Document = document;
        DocumentId = document.Id;
        Name = document.Name;
        Content = document.Content;
    }
}

This encapsulation ensures that all revision logic is properly handled in one place.

Step 6: Adding Revision Numbers and Timestamps

To further enhance revision tracking, we’ll add Revision numbers and TimeStamps to the DocumentBase class. This will allow us to track the history of changes more effectively.

public abstract class DocumentBase
{
    public DateTime TimeStamp { get; protected set; }
    public int Revision { get; protected set; }
}

public class Document : DocumentBase
{    
    public void CreateRevision()
    {
        TimeStamp = DateTime.UtcNow;
        Revision += 1;
        Revisions.Add(new DocumentRevision(this));
    }
}

Handling in `DocumentRevision`

Each DocumentRevision should inherit the revision number and timestamp from the original document when it’s created.

public class DocumentRevision : DocumentBase
{
    internal DocumentRevision(Document document)
    {
        Document = document;
        DocumentId = document.Id;
        Name = document.Name;
        Content = document.Content;
        TimeStamp = document.TimeStamp;
        Revision = document.Revision;
    }
}

Demonstrating the Revision Process

Let’s see how this works in practice together with a database.

NOTE: The TimeStamp field has been omitted from the tables below for clarity. You can track the revisions using the Revision number.

Create a new document:

var document = new Document
{
    Name = "My Document",
    Content = "Initial content"
};
context.Set<Document>().Add(document);
context.SaveChanges();

Id	Revision	IsRevision	Name	Content	DocumentId
3ef0de57...	0	false	My Document	Initial content	NULL

Create a revision and update the document:

document.CreateRevision();
document.Content = "Updated content";
context.Set<Document>().Update(document);
context.SaveChanges();

Id	Revision	IsRevision	Name	Content	DocumentId
3ef0de57...	1	false	My Document	Updated content	NULL
90f436e6...	0	true	My Document	Initial content	3ef0de57...

Create another revision and update the document’s name:

document.CreateRevision();
document.Name = "Updated Document";
context.Set<Document>().Update(document);
context.SaveChanges();

Id	Revision	IsRevision	Name	Content	DocumentId
3ef0de57...	2	false	Updated Document	Updated content	NULL
90f436e6...	0	true	My Document	Initial content	3ef0de57...
1e0d0ce0...	1	true	My Document	Updated content	3ef0de57...

Conclusion

By introducing revision support using discriminators in Entity Framework Core, you can track entity changes over time while keeping your data model simple. This flexible approach allows you to store both current and historical versions in the same table, making it easy to manage document versions and maintain a full audit trail.

However, will this same-table solution scale? Not indefinitely. If lookups on the active version are more common than on revisions, it’s wise to consider separating revisions into a different table, especially with large datasets. Fortunately, transitioning to a separate table for revisions is straightforward with this design — simply remove the discriminator setup from the ModelBuilder. Just remember to migrate your data when making the switch.

Last Recommendation

To avoid overwriting a Document without creating a revision, consider enforcing encapsulation on mutation methods. This will ensure consistent and reliable data tracking across your application.

Extending Ardalis.Specification for NHibernate with Linq, Criteria API, and Query Over

Jimmy — Mon, 16 Sep 2024 08:41:13 +0000

Ardalis.Specification is a powerful library that enables
the specification pattern for querying databases, primarily designed for Entity Framework Core,
but here I'll demonstrate how you can extend Ardalis.Specification to use NHibernate as an ORM as well.

This blog post assumes you have some experience with Ardalis.Specification, and want to use it in a
project using NHibernate. If you are not familiar with Ardalis.Specification yet, head over to the
documentation to learn more.

First, in NHibernate there are three different built-in ways to perform queries

Linq to query (using IQueryable)
Criteria API
Query Over

I'll go through how you can extend Ardalis.Specification to handle all 3 ways, but since Linq to Query
also works with IQueryable like Entity Framework Core, I'll go through that option first.

Linq to query

There is a small nuance between Entity Framework Core and NHIbernate when it comes to create join relationships.
In Entity Framework Core we have extensions methods on IQueryable: Include and ThenInclude
(these are also the method names used in Ardalis.Specification).
Fetch, FetchMany, ThenFetch and ThenFetchMany are NHibernate specific methods on IQueryable that do joins.
The IEvaluator gives us the extensibility we need to invoke the correct extension method when we work with NHibernate.

Add an implementation of IEvaluator as follows:

public class FetchEvaluator : IEvaluator
{
   private static readonly MethodInfo FetchMethodInfo = typeof(EagerFetchingExtensionMethods)
        .GetTypeInfo().GetDeclaredMethods(nameof(EagerFetchingExtensionMethods.Fetch))
        .Single();

   private static readonly MethodInfo FetchManyMethodInfo = typeof(EagerFetchingExtensionMethods)
       .GetTypeInfo().GetDeclaredMethods(nameof(EagerFetchingExtensionMethods.FetchMany))
       .Single();

   private static readonly MethodInfo ThenFetchMethodInfo
       = typeof(EagerFetchingExtensionMethods)
           .GetTypeInfo().GetDeclaredMethods(nameof(EagerFetchingExtensionMethods.ThenFetch))
           .Single();

   private static readonly MethodInfo ThenFetchManyMethodInfo
       = typeof(EagerFetchingExtensionMethods)
           .GetTypeInfo().GetDeclaredMethods(nameof(EagerFetchingExtensionMethods.ThenFetchMany))
           .Single();

    public static FetchEvaluator Instance { get; } = new FetchEvaluator();

    public IQueryable<T> GetQuery<T>(IQueryable<T> query, ISpecification<T> specification) where T : class
    {
        foreach (var includeInfo in specification.IncludeExpressions)
        {
            query = includeInfo.Type switch
            {
                IncludeTypeEnum.Include => BuildInclude<T>(query, includeInfo),
                IncludeTypeEnum.ThenInclude => BuildThenInclude<T>(query, includeInfo),
                _ => query
            };
        }

        return query;
    }

    public bool IsCriteriaEvaluator { get; } = false;

    private IQueryable<T> BuildInclude<T>(IQueryable query, IncludeExpressionInfo includeInfo)
    {
        _ = includeInfo ?? throw new ArgumentNullException(nameof(includeInfo));

        var methodInfo = (IsGenericEnumerable(includeInfo.PropertyType, out var propertyType)
            ? FetchManyMethodInfo 
            : FetchMethodInfo);

       var method = methodInfo.MakeGenericMethod(includeInfo.EntityType, propertyType);

       var result = method.Invoke(null, new object[] { query, includeInfo.LambdaExpression });
        _ = result ?? throw new TargetException();

        return (IQueryable<T>)result;
    }

    private IQueryable<T> BuildThenInclude<T>(IQueryable query, IncludeExpressionInfo includeInfo)
    {
        _ = includeInfo ?? throw new ArgumentNullException(nameof(includeInfo));
        _ = includeInfo.PreviousPropertyType ?? throw new ArgumentNullException(nameof(includeInfo.PreviousPropertyType));

        var method = (IsGenericEnumerable(includeInfo.PreviousPropertyType, out var previousPropertyType)
            ? ThenFetchManyMethodInfo
            : ThenFetchMethodInfo);

        IsGenericEnumerable(includeInfo.PropertyType, out var propertyType);

        var result = method.MakeGenericMethod(includeInfo.EntityType, previousPropertyType, propertyType)
            .Invoke(null, new object[] { query, includeInfo.LambdaExpression });

        _ = result ?? throw new TargetException();

        return (IQueryable<T>)result;
    }

    private static bool IsGenericEnumerable(Type type, out Type propertyType)
    {
        if (type.IsGenericType && (type.GetGenericTypeDefinition() == typeof(IEnumerable<>)))
        {
            propertyType = type.GenericTypeArguments[0];

            return true;
        }

        propertyType = type;

        return false;
    }
}

Next we need to configure ISpecificationEvaluator to use our FetchEvaluator (and other evaluators).
We add an implementation ISpecificationEvaluator as follows with the Evaluators configured in the constructor.
WhereEvaluator, OrderEvaluator and PaginationEvaluator are all in the Ardalis.Specification
and works well NHibernate as well.

public class LinqToQuerySpecificationEvaluator : ISpecificationEvaluator
{
    private List<IEvaluator> Evaluators { get; } = new List<IEvaluator>();

    public LinqToQuerySpecificationEvaluator()
    {
        Evaluators.AddRange(new IEvaluator[]
        {
            WhereEvaluator.Instance,
            OrderEvaluator.Instance,
            PaginationEvaluator.Instance,
            FetchEvaluator.Instance
        });
    }


    public IQueryable<TResult> GetQuery<T, TResult>(IQueryable<T> query, ISpecification<T, TResult> specification) where T : class
    {
        if (specification is null) throw new ArgumentNullException(nameof(specification));
        if (specification.Selector is null && specification.SelectorMany is null) throw new SelectorNotFoundException();
        if (specification.Selector is not null && specification.SelectorMany is not null) throw new ConcurrentSelectorsException();

        query = GetQuery(query, (ISpecification<T>)specification);

        return specification.Selector is not null
            ? query.Select(specification.Selector)
            : query.SelectMany(specification.SelectorMany!);
    }

    public IQueryable<T> GetQuery<T>(IQueryable<T> query, ISpecification<T> specification, bool evaluateCriteriaOnly = false) where T : class
    {
        if (specification is null) throw new ArgumentNullException(nameof(specification));

        var evaluators = evaluateCriteriaOnly ? Evaluators.Where(x => x.IsCriteriaEvaluator) : Evaluators;

        foreach (var evaluator in evaluators)
           query = evaluator.GetQuery(query, specification);

        return query;
    }
}

Now we can create a reference to LinqToQuerySpecificationEvaluator
in our repository that may look something like this:


public class Repository : IRepository
{
    private readonly ISession _session;
    private readonly ISpecificationEvaluator _specificationEvaluator;

    public Repository(ISession session)
    {
        _session = session;
        _specificationEvaluator = new LinqToQuerySpecificationEvaluator();
    } 

    ... other repository methods

    public IEnumerable<T> List<T>(ISpecification<T> specification) where T : class
    {
        return _specificationEvaluator.GetQuery(_session.Query<T>().AsQueryable(), specification).ToList();
    }

    public IEnumerable<TResult> List<T, TResult>(ISpecification<T, TResult> specification) where T : class
    {    
        return _specificationEvaluator.GetQuery(_session.Query<T>().AsQueryable(), specification).ToList();
    }

    public void Dispose()
    {
        _session.Dispose();
    }
}

That's it. We can now use Linq to Query in our specifications just like we normally do with Ardalis.Specification:

public class TrackByName : Specification<Core.Entitites.Track>
{
    public TrackByName(string trackName)
    {
        Query.Where(x => x.Name == trackName);
    }
}

Now that we've covered Linq-based queries, let's move on to handling Criteria API and Query Over, which require a different approach.

Mixing Linq, Criteria, and Query Over in NHibernate

Since Criteria API and Query Over has their own implementation to generate SQL, and doesn't use IQueryable,
they are incompatible with the IEvaluator interface. My solution is to avoid using the IEvaluator interface for these methods
in this case, but rather focus on the benefits of the specification pattern. But I also want to be able to mix
Linq to Query, Criteria and Query Over with in my solution (if you only need one of these implementations, you can
cherry-pick for your best needs).

To be able to do that, I add four new classes that inherits Specification or Specification

NOTE: The assembly where you define these classes needs a reference to NHibernate as we define actions
for Criteria and a QueryOver, that can be found in NHibernate

public class CriteriaSpecification<T> : Specification<T>
{
    private Action<ICriteria>? _action;
    public Action<ICriteria> GetCriteria() => _action ?? throw new NotSupportedException("The criteria has not been specified. Please use UseCriteria() to define the criteria.");
    protected void UseCriteria(Action<ICriteria> action) => _action = action;
}

public class CriteriaSpecification<T, TResult> : Specification<T, TResult>
{
    private Action<ICriteria>? _action;
    public Action<ICriteria> GetCriteria() => _action ?? throw new NotSupportedException("The criteria has not been specified. Please use UseCriteria() to define the criteria.");
    protected void UseCriteria(Action<ICriteria> action) => _action = action;
}

public class QueryOverSpecification<T> : Specification<T>
{
    private Action<IQueryOver<T, T>>? _action;
    public Action<IQueryOver<T, T>> GetQueryOver() => _action ?? throw new NotSupportedException("The Query over has not been specified. Please use the UseQueryOver() to define the query over.");
    protected void UseQueryOver(Action<IQueryOver<T, T>> action) => _action = action;
}

public class QueryOverSpecification<T, TResult> : Specification<T, TResult>
{
    private Func<IQueryOver<T, T>, IQueryOver<T, T>>? _action;
    public Func<IQueryOver<T, T>, IQueryOver<T, T>> GetQueryOver() => _action ??  throw new NotSupportedException("The Query over has not been specified. Please use the UseQueryOver() to define the query over.");
    protected void UseQueryOver(Func<IQueryOver<T, T>, IQueryOver<T, T>> action) => _action = action;
}

Then we can use pattern matching in our repository to change how we do queries with NHibernate


public IEnumerable<T> List<T>(ISpecification<T> specification) where T : class
{
    return specification switch
    {
        CriteriaSpecification<T> criteriaSpecification => 
            _session.CreateCriteria<T>()
                .Apply(query => criteriaSpecification.GetCriteria().Invoke(query))
                .List<T>(),

        QueryOverSpecification<T> queryOverSpecification => 
            _session.QueryOver<T>()
                .Apply(queryOver => queryOverSpecification.GetQueryOver().Invoke(queryOver))
                .List<T>(),

        _ => _specificationEvaluator.GetQuery(_session.Query<T>().AsQueryable(), specification).ToList()
    };
}

public IEnumerable<TResult> List<T, TResult>(ISpecification<T, TResult> specification) where T : class
{

    return specification switch
    {
        CriteriaSpecification<T, TResult> criteriaSpecification => 
            _session.CreateCriteria<T>()
                .Apply(query => criteriaSpecification.GetCriteria().Invoke(query))
                .List<TResult>(),

        QueryOverSpecification<T, TResult> queryOverSpecification =>
            _session.QueryOver<T>()
                .Apply(queryOver => queryOverSpecification.GetQueryOver().Invoke(queryOver))
                .List<TResult>(),

        _ => _specificationEvaluator.GetQuery(_session.Query<T>().AsQueryable(), specification).ToList()
    };
}

The Apply() method above are an extension method that simplifies the query to a single line:

public static class QueryExtensions
{
    public static T Apply<T>(this T obj, Action<T> action)
    {
        action(obj);
        return obj;
    }

    public static TResult Apply<T, TResult>(this T obj, Func<T, TResult> func)
    {
        return func(obj);
    }
}

Criteria specification example

NOTE: The assembly where you define these classes needs a reference to NHibernate as we define actions
for Criteria, that can be found in NHibernate

public class TrackByNameCriteria : CriteriaSpecification<Track>
{
    public TrackByNameCriteria(string trackName)
    {
        this.UseCriteria(criteria => criteria.Add(Restrictions.Eq(nameof(Track.Name), trackName)));
    }
}

Query over specification example

NOTE: The assembly where you define these classes needs a reference to NHibernate as we define actions
for a QueryOver, that can be found in NHibernate

public class TrackByNameQueryOver : QueryOverSpecification<Track>
{
    public TrackByNameQueryOver(string trackName)
    {
        this.UseQueryOver(queryOver => queryOver.Where(x => x.Name == trackName));
    }
}

By extending Ardalis.Specification for NHibernate, we unlock the ability to use Linq to Query,
Criteria API, and Query Over—all within a single repository pattern. This approach offers a
highly adaptable and powerful solution for NHibernate users

Immutable DTOs in C# with interfaces

Jimmy — Fri, 28 Feb 2020 17:03:38 +0000

By using interfaces instead of classes when transferring data between our application layers, we can achieve immutability by only defining the getters in the interface.

public interface IEmployeeDto
{
    string Name { get; }
    string EmployeeNumber { get; }
}

The implementation of IEmployeeDto may have the setters to get the benefit of object initializers, just as a regular POCO.

public class EmployeeDto : IEmployeeDto 
{
    string Name { get; set; }
    string EmployeeNumber { get;  set; }
}

public class EmployeeService
{
    private readonly EmployeeRepository _employeeRepository;

    public EmployeeService(EmployeeRepository employeeRepository)
    {
        _employeeRepository = employeeRepository;
    }


    public void CreateNewEmployee(string name, string employeeNumber)
    {
        _employeeRepository.Add(new EmployeeDto()
        {
             Name = name,
             EmployeeNumber = employeeNumber
        }
    }
}

public class EmployeeRepository
{
    publc void Add(IEmployeeDto employee)
    {
        //employee is immutable
    }
}

Other implementations

That's the basics of it, but using interfaces as DTO's allow us to do more fun stuff with our code. I do a lot of integrations with other systems, and their api models never matches ours (surprise!). What I then do is something like the adapter pattern.

public interface IExternalEmployeeDto
{
    string FirstName { get; }
    string LastName { get; }
    int EmployeeNumber { get; }
}

public class ExternalEmployeeDto : IExternalEmployeeDto
{
    public string FirstName { get; set; }
    public string LastName { get; set; }
    public int EmployeeNumber { get;  set; }
}

public class EmployeeDto : IEmployeeDto 
{
    private readonly IExternalEmployeeDto _externalDto;

    string Name => "${_externalDto.FirstName} {_externalDto.LastName}";
    string EmployeeNumber => _externalDto.EmployeeNumber.ToString();

    public EmployeeDto(IExternalEmployeeDto externalDto)
    {
        _externalDto = externalDto;
    }
}

public class ExternalEmployeeService
{     
    private readonly EmployeeRepository _employeeRepository;

    public ExternalEmployeeService(EmployeeRepository employeeRepository)
    {
        _employeeRepository = employeeRepository;
    }

    public void CreateNewEmployee(IExternalEmployeeDto externalDto)
    {
        _employeeRepository.Add(new EmployeeDto(externalDto);
    }
}

Testing

Testing is another fun part that becomes easier with interface DTOs, as they don't depend on real implementations. We can create a Stub class for the interface with default values in the constructor (I must say, it does help to have ReSharper with the ctorp-snippet when it comes to create these).

public class StubExternalEmployeeDto : IExternalEmployeeDto
{
    public string FirstName { get; }
    public string LastName { get; }
    public int EmployeeNumber { get; }

    public StubExternalEmployeeDto(string firstName = "Jimmy", string lastName= "Mattsson", int empoyeeNumber = 1000)
    {
         FirstName = firstName;
         LastName = lastName;
         EmployeeNumber = empoyeeNumber;
    }
}

[TestFixture]
public class EmployeeDtoTests
{
    [Test]
    public void ShouldMapExternalEmployeeDtoToEmployeeDto()
    {
        //Asserting Name with default values
        Assert.AreEqual("Jimmy Mattsson", new EmployeeDto(new StubExternalEmployeeDto()).Name);

        //Asserting Name with diffrent LastName from default
        Assert.AreEqual("Jimmy Coding", new EmployeeDto(new StubExternalEmployeeDto(lastName: "Coding")).Name);

        //Asserting EmployeeNumber diffrent from default
        Assert.AreEqual("5000", new EmployeeDto(new StubExternalEmployeeDto(empoyeeNumber: 5000)).EmployeeNumber);
    }
}

Experiences

I must be horrible at testing, because almost all my time goes into making testing easier, so that I one day can become productive. The idea of using interfaces as DTOs actually comes from one of those experiences, when I had a much larger and nested model to work with.

The immutability actually came after that, it wasn't something I was hunting for and I take that as a bonus. To make the timeline correct, this article should be read backwards.

Trade-offs

Everything has trade-offs, so does this implementation. Having multiple implementations of an interface, both in production code and tests, makes it harder to change the interface. But as I view it, those interfaces are the contracts that our current business rules builds upon, if the interfaces changes, so have the business rules. It's an opportunity to look over all those implementations.

Upside is that the project won't even build if the updated interface isn't implemented. On other hand, the alternative to reusing the same class DTO in multiple cases may lead to some DTOs being overlooked.

Have I missed something? Comment!

Explore!

I admit, this may be a little over engineering in most cases. It's data being passing around between layers, it may not being suitable for a CRUD application.

But it's for a good cause, to make those complex test cases easier. I encourage you to explore and try things out. I've only written one test in this article, and it's testing getters. But the true power comes when there is more complexity, when the code should return different result depending on the input. At least I and my team has become more productive with this.

And you get immutability. If you need that.

Simplify arranging of dependencies in tests

Jimmy — Sat, 16 Nov 2019 12:23:24 +0000

I have created a NuGet package to simplify the arrange step when writing tests, that's useful when you use dependency injection.

Basic use

nuget install ArrangeDependencies.Autofac

var arrange = Arrange.Dependencies(dependencies =>
{
    dependencies.UseImplementation<IUserService, UserService>();
});

var userService = arrange.Resolve<IUserService>();

// Act

// Assert

This will produce a UserService to start testing on. All the injected dependencies in UserService will be injected as Mock.Of<T>(), resulting in methods calls on any dependency will return the default value of the return type.

When adding more dependencies to the UserService you do not need to change all the tests setups that you have already created. You may, however, still need to change some tests if the behavior has changed.

This arrange block can be simplified by a one liner

var arrange = Arrange.Dependencies<IUserService, UserService>();

This setup will call on UseImplementation<IUserService, UserService>() under the hood.

Use Mock

nuget install ArrangeDependencies.Autofac

var arrange = Arrange.Dependencies<IUserService, UserService>(dependencies =>
{
    dependencies.UseMock<IUserRepository>(mock => {
        mock.Setup(x => x.GetByName(It.IsAny<string>())).Returns(new Basis.Entites.User());
    });
});

Now UserService will use your mocked IUserRepository, instead of the default Mock.Of<T>(), and return a new User when GetByName(name) is called. The mock action is like any other Mock setup that you probably already is used to.

Use DbContext

nuget install ArrangeDependencies.Autofac.EntityFrameworkCore

var arrange = Arrange.Dependencies(dependencies =>
{
    dependencies.UseDbContext<TestDbContext>();
});

This will setup an in memory database for TestDbContext in your test.

Use Entity

nuget install ArrangeDependencies.Autofac.EntityFrameworkCore

var arrange = Arrange.Dependencies(dependencies =>
{
    dependencies.UseEntity<User, TestDbContext>((user) => user.SetName("Test name"));
});

This will add a new user into TestDbContext that can be used in testing. NOTE: UseDbContext is called under the hood here, so you don't need to define it.

var arrange = Arrange.Dependencies(dependencies =>
{
    dependencies.UseEntity<Company, TestDbContext>((company) => company.SetName("Test name"), out var company);
    dependencies.UseEntity<User, TestDbContext>((user) => {
        user.SetName("Test name");
        user.SetCompany(company);
    });
});

You can also couple the entites by using the out parameter.

Use MemoryCache

nuget install ArrangeDependencies.Autofac.MemoryCache

var user = "Cache test user"

var arrange = Arrange.Dependencies<IUserService, UserService>(dependencies =>
{
    dependencies.UseMemoryCache("Cache test", user);
});

With this you can test your cache, where the first parameter is the key and the second is the cached object.

Use Logger

nuget install ArrangeDependencies.Autofac.Logger

Mock<ILogger<LoggingService>> logger = null;

var arrange = Arrange.Dependencies<ILoggingService, LoggingService>(dependencies =>
{
    dependencies.UseLogger(out logger);
});

var loggingService = arrange.Resolve<ILoggingService>();
loggingService.LogError();

logger.Verify(LogLevel.Error, Times.Once());

With this you can verfy that you log errors (or any other Log Level).

Create your own extensions

This library is extensible by nature, so if you find yourself writing the same mock setup over and over again, I suggest you to create your own extension method for that mock.

public static class UseMyCustomExtensionExtension
{
    public static IArrangeBuilder<ContainerBuilder> UseMyCustomExtension(this IArrangeBuilder<ContainerBuilder> arrangeBuilder, /* parameters... */)
    {
        if(arrangeBuilder is ArrangeBuilder builder)        
            builder.UseMock<IMyCustomExtension>(mock => /* setup mock here */);

        return arrangeBuilder;
    }
}

Holding your first interview

Jimmy — Sat, 14 Sep 2019 12:34:14 +0000

I've always worked for smaller companies/start ups with less than 20 empoyees. In my experience, as soon my employer trust me enough, I'll be asked to join an ongoing interview and expected to ask the right questions.

The first time this happened I was totally unprepared. My boss asked me to join the ongoing interview and then asked me if I had any questions for the candidate. "Do you know XML" I asked (this was back in 2007) and the candidate replied "Yes".

That was enough to give the candidate the job. I got lucky, becouse he turned out to know alot more than XML and he stayed within the company for a decade.

Since then I've done a few more of those awkward interviews. But everything changed after reading this article, I suggest you do the same, but in conclusion, knowing what you are looking for in a candidate helps out alot!

Right after reading that article I told my employer that I want to interview our candidates next time we need more developers on our team. This brought me two benefits:

No more surprise interviews, I can be prepared.
The candidate might become my co-worker, I can now get a glimpse on how well we'll work together.

The second bullet point is for me the most important thing I try to figure out during my interview. Other things I find important are culture fit, in this case how curious the candidate are to learn new things and their ability to pay their new learning's forward.

I ask the candidate questions about in what ways they learn new topics and trying to start a discussion about anything they just learnt. The candidates are often nervous (and so am I) but it helps to steer the discussion into something they know well and have strong feelings about. My goal with my question is to be able to answer the question: Is this candidate a culture fit?

When I'm done with my questions/discussions I'll let the candidate create a small console game (I'll come back to that) writing real code. I keep hearing about interviews where the candidate gets to solve a fizz buzz or an complex algorithm on a whiteboard, but that wouldn't answer the question: Can we work together?

Once the candidate starts coding my challange, I'm able to get a sense of his/hers coding standards, coding principles and their thought process. We solve the problem together with their design and thoughts.

The challenge is to create a console game in five steps, each step changing the rules of the game (almost like real world programming).

Step 1: Create a console game with two players. Each player take a guess on number between 0-100. The player that is closest to a random number between 0-100 wins.

Step 2: Add three guessing turns (on the same random number). If a player guesses the right number they win, otherwise the closest player on the last guessing turn wins. After each turn the game should give a hint on who is closest.

Step 3: Add a choice to start the game with 2,3 or 4 players.

Step 4: Change number of guessing turns depending on how many players:

2 players, 5 turns
3 players, 4 turns
4 players, 3 turns

Step 5: Change the random interval depending on number of players:

2 players, 0-100
3 players, 0-250
4 players, 0-500

As a final challenge, I let the candidate to redo step 5, but with code that I have written.

After this I'm able to understand the candidate's thought proccess and how well he/she understands code that has been written by someone else. I'm also able to answer the question: Can we work together?

I've given you an insight of my process when interviewing. It may not be perfect in every case, and I might tweak the details over time.

To round things up, my advice to you is:

If possible, take the chance and take part in the interviewing process.
Prepare yourself for the interview, know what questions you should be able to answer after the interview and design your questions and coding challenges to find those answers.

Remember that this might the first time you meet a future co-worker. Remember that you are in a position of power, avoid to use it in a bad way, that could result in a bad start on your future collaboration.

Nested builders with Action

Jimmy — Tue, 10 Sep 2019 18:28:23 +0000

Once I started to use the Builder Pattern it didn't take long until I faced more complex objects on multi levels.

My first solution to this was to add a method returning a new Builder and in that builder have a Complete method that would return my original Builder.

Sounds complex doesn't it? It sure is! Once I got beyond 2 levels of nesting the builder implementation was a real hell every time.

Then I discovered I could use Action, where T is another Builder. This made my builders easier to implement, and also easier to maintain.

Here's a code example on how it could look like:

public class Person
{
    public string Firstname { get; set; }
    public string Lastname { get; set; }
    public List<Person> Children { get; set }
}

public class PersonBuilder 
{
    private readonly Person _person;

    public PersonBuilder()
    {
        _person = new Person();
    }

    public PersonBuilder Firstname(string firstname)
    {
        _person.Firstname = firstname;

        return this;
    }

    public PersonBuilder Lastname(string lastname)
    {
        _person.Lastname = lastname;

        return this;
    }

    public PersonBuilder AddChild(Action<PersonBuilder> builder)
    {
        var personBuilder = new PersonBuilder();
        builder(personBuilder);

        _person.Children.Add(personBuilder.Build())

        return this;
    }

    public Person Build()
    {
        return _person;
    }
}

var person = new PersonBuilder()
                        .Firstname("John")
                        .Lastname("Doe")
                        .AddChild(child => {
                               child.Firstname("Jane")
                                    .Lastname("Doe")
                        })
                        .Build();