C# - Automapper vs Factory Methods

When converting data from one model to another, there is often the thought over whether it would be beneficial to use automapper or whether factory methods should be used to explicitly convert between models. I'm going to explain what each of these is, and explain a couple of advantages and disadvantages of each.

Automapper

Automapper is a NuGet package that allows you to "get rid of code that mapped one object to another". It is convention based, and if there are a large number of properties that are identical on 2 classes it can save a lot of developer time converting between objects. It also means that less code can be written for this conversion... Yay! However, there are a couple of disadvantages that come with convention based as opposed to explicit programming, and Automapper is no exception!

If you are using Automapper with default mappings and refactor the name of the source/target model, then you won't necessarily know until runtime because it won't cause a compile time error. The issue is that if there is a rename of the property, automapper will no longer be able to map correctly. Whereas if you were to explicitly code the conversion, there would be a compile time error so you can identify the error earlier. The risk of this failed mapping occurring can be mitigated by unit testing the mapping.

A similar issue to this is that there is a lack of static analysis. For example, if you find all references of a property it may look like nothing is referencing that property so you may be tempted to remove it. However, automapper could be mapping to this property without you even realising.

Overall, Automapper is a well tested library that can save you time writing uninspiring conversion code, but there are downsides and different scenarios may mean that it is beneficial or not.

Factory Methods

Factory methods allow you to explicitly convert between objects. Due to the explicit conversion, it is easy for developers working on the same project to see where values are coming from. This is because it is not hidden behind a library that the developer may or may not be familiar with. It is also easier to debug. If mapping is done incorrectly there will also be compile time errors which can help catch issues earlier.

Of course, there is a reason the Automapper NuGet package exists and this is because the manual conversion is tedious and takes time that could be spent on other things. The manual conversion also means that there is more code sitting in your project. Additionally, with anything manual there is the chance of human error and 2 properties that don't actually align with each other could potentially be mapped. Your unit tests should pick this up though.

When trying to choose between Automapper and Factory methods, think about your code and how well the objects will map automatically without configuration. Secondly, consider the important of static analysis and compile time errors in your code. This isn't a one-size fits all comparison, it's case by case as to which will be beneficial!

C# - Extension Methods

Extension methods allow you to extend functionality of a specific type. It is a special kind of static method that you can call as if it were an instance method on the object of the specified type. Extension methods are simple to define and you can define them as follows:

  using System;
     
  public class Program
  {
    public static void Main()
    {
      string message = "Hello World";
      Console.WriteLine(message.GetDatedMessage());
    }
  }

  // Extension methods must be contained within a non-generic static class
  public static class StringExtensions 
  {
    // Extension methods must be static
    // Extended object must be prefixed with this
    public static string GetDatedMessage(this string message) {
      return String.Format("{0}: {1}", DateTime.Now, message);
    }
  }

Visual Studio - How to generate a NuGet package on build

NuGet packages are extremely useful way to add libraries/components to your code base. This is similar to the traditional way of referencing DLLs except that you get notifications when there are updates.

You may find that if your code lives in separate Git repositories that if someone wants to use a project from one Git repo in another Git repo that they would need to download both. However, NuGet packages can be stored in a common location e.g. the NuGet Package Gallery which is available to all, or on a centralised private NuGet server. If you want to use a private NuGet server, you will need to add a package source in the NuGet package manager. You can do this by clicking the little cog next to "Package source".

Now for actually generating the NuGet package you can do this automatically on build, by opening a right clicking on a project and selecting properties. Then navigate to the "Package" tab and check "Generate NuGet package on build"