From Converters to Dependency Injection: Navigating Model Migrations
Tags: csharp, designpatterns, programming, dotnet
Published: 2023-09-29 14:47:50

Do you know the three-layer software design? Think of it as tech's equivalent of a sandwich with neatly stacked presentation, logic, and data layers. Now, why choose multiple models over one mammoth model? It's akin to organizing playlists by mood. Nifty, isn't it? In the coding realm, it's about being spick and span. Tiny model tweaks feel more like a brisk walk than a marathon.

But the real query is: how do we flit between models within these layers, especially when models diverge or beckon another repo or service?

## Well, Examples Speak Louder
### Keep It Simple
Suppose a Dog is set to evolve into a DogDto.

``` csharp
public class Dog
{
    public string Name { get; set; }
}

public class DogDto
{
    public string Name { get; set; }
}
```
Seems direct, right? Either use AutoMapper:
``` csharp
Dog dog = new Dog{ Name = "doge"};
DogDto dogDto = _mapper.Map<DogDto>(dog);
```

Or, take the traditional route:
``` csharp
Dog dog = new Dog{ Name = "doge"};
DogDto dogDto = new DogDto { Name = dog.Name };
```

### Navigating Naming Nuisances
What if DogDto opts for a different nomenclature?

``` csharp
public class Dog
{
    public string Name { get; set; }
}

public class DogDto
{
    public string Naming { get; set; }
}
```
You've got two aces up your sleeve: use a FromXX/ToXX method or integrate a mapper profile. Here's option one:
``` csharp
public class DogDto
{
    public string Naming { get; set; }

    public static DogDto FromDog(Dog dog)
    {
        return new DogDto
        {
            Naming = dog.Name
        };
    }
}
```
And here you have how would mapper profile look like:
``` csharp
using AutoMapper;

public class UserProfile : Profile
{
    public UserProfile()
    {
        CreateMap<Dog, DogDto>()
            .ForMember(dest => dest.Naming, opt => opt.MapFrom(src => src.Name));
    }
}
```
```csharp
var configuration = new MapperConfiguration(cfg =>
{
     cfg.AddProfile<UserProfile>();
});
```

### When Models are Like Apples and Oranges
``` csharp
public class Dog
{
    public string Name { get; set; }
}

public class DogDto
{
    public int NumberOfLegs { get; set; }
    
    public Superpower SuperPower  { get; set; }
}
```
Time to roll up the sleeves! Converters are the knights in shining armor here:

``` csharp
public interface IConverter<In, Out>
{
    Out Convert(In input);
}

public class DogConverter : IConverter<Dog, DogDto>
{
    // Your conversion magic here!
}
```

## Elevate Your Game: Services Within Converters
Ever bumped into a situation where your models are as different as, well, apples and oranges? And, to spice things up, you need to juggle an `AnimalRepository` or a `FoodService` within your converter. Tough spot, right?

Remember this code?
``` csharp
var converter = new DogConverter(_animalRepository, _foodService, _anotherService, _pleaseStopThisIsTooMuch, userId);
``` 
It might remind you of the infamous spaghetti mess. But fear not, there's a cleaner approach. Let me share a neat trick I've brewed up!

### Step into the World of ConverterFactory
A `ConverterFactory` is like a genie granting your converter wishes.
``` csharp
public class ConverterFactory
{
    private readonly IServiceProvider _serviceProvider;

    public ConverterFactory(IServiceProvider serviceProvider)
    {
        _serviceProvider = serviceProvider;
    }

    public IConverter<InType, OutType> GetConverter<InType, OutType>()
    {
        var converter = _serviceProvider.GetService(typeof(IConverter<InType, OutType>));
        if (converter == null)
        {
            throw new Exception("Missing converter alert!");
        }

        return (IConverter<InType, OutType>)converter;
    }
}
``` 
### Boot Things Up in Startup.cs
Here's where we align our forces. Add your services to the service collection:
```csharp 
services.AddTransient<ConverterFactory>();
services.AddTransient<IConverter<Dog, DogDto>, DogConverter>();
services.AddTransient<IAnimalRepository, AnimalRepository>();
services.AddTransient<IFoodService, FoodService>();
``` 

### Smooth Operations with DogHelper
With everything set, it's showtime:
```csharp 
public class DogHelper
{
    private readonly ConverterFactory _converterFactory;
    public DogHelper(ConverterFactory converterFactory)
    {
        _converterFactory = converterFactory;
    }

///...
    public DogDto TransformDog(Dog input)
    {
        var converter = _converterFactory.GetConverter<Dog, DogDto>();
        return converter.Convert(input);
    }
}
```

What's the magic? No more manually creating converter instances and wrestling with services. Dependency injection sweeps in, handling all the heavy lifting ensuring cleaner and more efficient code. 

## Wrapping Up: A Fresh Look at Tools and Tactics
### Is Automapper Outdated? Let's Debate
Let me drop a bombshell: Could Automapper be sliding into obsolescence? I recently found myself locked in a spirited dialogue with a colleague about its continuing relevance. The crux of the debate? Automapper's Achilles' heel is its runtime error reporting. Get a property name or type conversion wrong, and you're signing up for bug city.

Sure, Automapper shone when replicating models that were virtually identical, especially those property-heavy behemoths we often see in enterprise settings. But let’s be real: Visual Studio's ultra-efficient auto-code completion has redefined the game, making that argument a little wobbly.

### ConverterFactory: A Quick Fix, But Not a Cure-All
Time to tackle the not-so-hidden issue: If you find yourself leaning heavily on something like a ConverterFactory, coupled with dependency injection, it might be time to sniff out potential architectural odors. Could it be a red flag suggesting you revisit your system’s blueprints?

## The Final Takeaway
So, there we are! Whether you're nodding along or vigorously shaking your head, my hope is that this exploration has sparked some intellectual kindling. Got a different approach? Differing opinions? Lay it on me. Let's remember that achieving perfection is less a destination and more an ever-evolving journey. There's always room for development and refinement in the ever-changing tech landscape. So go ahead, share your insights—I'm more than ready for a good round to disscuss!