Customizing the Equipment Entity

By the default the microservice template creates a dummy entity using the name we put on the --EntityName parameter when executing the template. Look for the Equipment.cs file in the ITsynch.Suite.Equipments.Domain project.

namespace ITsynch.Suite.Equipments.Domain
{
    public class Equipment : ICorrelatedEntity
    {
        public Equipment(Guid correlationId)
        {
            this.CorrelationId = correlationId;
        }

        public Guid CorrelationId { get; private set; }

        public string DisplayName { get; private set; } = null!;

        public void SetDisplayName(string newName)
        {
            // TODO: validate newName and throw exceptions.
            this.DisplayName = newName;
        }
    }
}

This entity already has a CorrelationId and a DisplayName. We will keep them, because the CorrelationId is required as it is the Unique ID, and the DisplayName conventionally is the string representation of the entity.

Adding a new property

We will add a new string property called Code as follows:

public string Code { get; private set; } = null!;

Notice how we are making the setter private. This is intentional, as we want the state of the object to be modified through its methods, we do not want anemic models. For now, we are just going to add a simple one:

public void SetCode(string newCode)
{
    this.Code = newCode;
}

Mapping the new property on Entity Framework

We have added a new field to the entity, but we still need to map it so EF knows how to store it on the database. The microservice template has already created the mapping for the entity on the ITsynch.Suite.Equipments.Persistence project under the ClassMappings directory:

internal class EquipmentEntityTypeConfiguration
    : IEntityTypeConfiguration<EquipmentsDbContext, Equipment>
{
    public void Configure(EntityTypeBuilder<Equipment> builder)
    {
        builder.DisplayNameProperty(x => x.DisplayName);
    }
}

The EntityTypeBuilder class allows us to set properties to be stored on the database, and also specify how (length, nullability, etc.). Lets add the Code property, with a maximum allowed length of 40 characters:

builder.Property(x => x.Code).HasMaxLength(40);

Mapping the GraphQL Entity

By default the microservice template adds configuration for GraphQL queries. We will learn this in detail in the following chapters, but for now lets add the required changes so we can run the service without any issues. Lets find the Equipment class on the GraphQL folder on the contracts project and add there the Code property. It must be nullable.

namespace ITsynch.Suite.Equipments.Application.GraphQL
{
    /// <summary>
    /// Dto for GraphQL queries.
    /// </summary>
    public record Equipment
    {
        /// <summary>
        /// Gets or sets the Correlation Id.
        /// </summary>
        public Guid? CorrelationId { get; set; } = null!;

        /// <summary>
        /// Gets or sets the Display Name.
        /// </summary>
        public string? DisplayName { get; set; } = null!;

        /// <summary>
        /// Gets or sets the Code.
        /// </summary>
        public string? Code { get; set; } = null!;
    }
}

Then lets add the Code property on the AutoMapper profile. Lets find the EquipmentProfile and add the mapping as follows:

namespace ITsynch.Suite.Equipments.Application.GraphQL
{
    internal class EquipmentProfile : Profile
    {
        public EquipmentProfile()
        {
            this.CreateMap<Domain.Equipment, GraphQL.Equipment>()
                .ForMember(dto => dto.CorrelationId, b => b.MapFrom(entity => entity.CorrelationId))
                .ForMember(dto => dto.DisplayName, b => b.MapFrom(entity => entity.DisplayName))
                .ForMember(dto => dto.Code, b => b.MapFrom(entity => entity.Code));
        }
    }
}

Creating migrations

The last thing we need to do to have a basic persistance setup up and running is to create the migrations for our current model. Migrations allows us to track changes on the model, to then be able to apply those changes to the corresponding database. (On relational DBs this means creating tables, columns, etc.) To do so, lets run the following inside the dotnet directory.

dotnet ef migrations add InitialCreate \
    --startup-project src/services/Equipments/ITsynch.Suite.Equipments.Application \
    --project src/services/Equipments/ITsynch.Suite.Equipments.Persistence.SqlServerProvider \
    --output-dir Migrations

• dotnet ef migrations add: this command is used to create migrations.
• InitialCreate: the first parameter is the name of the migration, in this case InitialCreate.
• --startup-project: the executable project.
• --project: the project where the migrations should be stored.
• output-dir: the directory within the project where the migrations are going to be stored.

The generated files should appear on the output directory:

The Suite Framework will automatically validate the database on startup and run any pending migration if required. We can run the application to validate this. If we run the application now, we should see the following on the log:

Executing migrator ITsynch.Suite.EntityFrameworkCore.EFCoreMigrationsExecutor[ITsynch.Suite.Equipments.Persistence.EquipmentsDbContext]

We can also check the database:

There we can see that a table was created for our entity, with its corresponding columns.