DEV Community: Ignacio laborde

Entity Framework Core: Simplify your queries with AutoMapper

Ignacio laborde — Sat, 30 Apr 2022 23:37:22 +0000

For the examples of code, we are going to use the following entities:

public class Blog
{
    public int Id { get; set; }
    public string Name { get; set; }
    public ICollection<Post> Posts { get; set; }
}

public class Post
{
    public int Id { get; set; }
    public string Title { get; set; }
    public Blog Blog { get; set; }
    public List<Comment> Comments { get; set; }
}

public class Comment
{
    public int Id { get; set; }
    public string Content { get; set; }
    public Post Post { get; set; }
}

And DTOs:

public class PostDto
{
    public int Id { get; set; }
    public string Title { get; set; }
    public int BlogId { get; set; }
    public string BlogName { get; set; }
    public List<CommentDto> CommentsDto { get; set; }
}

public class CommentDto
{
    public int Id { get; set; }
    public string Content { get; set; }
}

public class PostSummaryDto
{
    public int Id { get; set; }
    public string Title { get; set; }
    public int CommentsCount { get; set; }
}

When querying data with Entity Framework is very common to use the Include method. But that can have two drawbacks: you will query fields that probably you don't need, and the second one maybe you will need to map your entities to another model or DTO.

var posts = await dbContext.Posts
    .Include(x => x.Blog)
    .Include(x => x.Comments)
    .ToListAsync();

// map to DTO

For this query Entity Framework will generate the following SQL code:

SELECT [p].[Id], [p].[BlogId], [p].[Title], [b].[Id], [b].[Name], 
    [c].[Id], [c].[Content], [c].[PostId]
FROM [Posts] AS [p]
INNER JOIN [Blogs] AS [b] ON [p].[BlogId] = [b].[Id]
LEFT JOIN [Comments] AS [c] ON [p].[Id] = [c].[PostId]
ORDER BY [p].[Id], [b].[Id]

An existing way to solve this is using a projection, just picking the fields that you need and using directly the DTO instead of entities:

var post = await dbContext.Posts
    .Select(x => new PostDto()
    {
        Id = x.Id,
        Title = x.Title,
        BlogId = x.Blog.Id,
        BlogName = x.Blog.Name,
        CommentsDto = x.Comments.Select(c => new CommentDto()
        {
            Id = c.Id,
        }).ToList()
    })
    .ToListAsync();

With the following query as result:

SELECT [p].[Id], [p].[Title], [b].[Id], [b].[Name], [c].[Id]
FROM [Posts] AS [p]
INNER JOIN [Blogs] AS [b] ON [p].[BlogId] = [b].[Id]
LEFT JOIN [Comments] AS [c] ON [p].[Id] = [c].[PostId]
ORDER BY [p].[Id], [b].[Id]

But manually writing the query can be a bit tedious.

ProjectTO to the rescue

AutoMapper has a simple way to solve this using the .ProjectTo method:

var posts = await mapper.ProjectTo<PostDto>(dbContext.Posts, null).ToListAsync();

Generating exactly the same query as the projection:

SELECT [p].[Id], [p].[Title], [b].[Id], [b].[Name], [c].[Id]
FROM [Posts] AS [p]
INNER JOIN [Blogs] AS [b] ON [p].[BlogId] = [b].[Id]
LEFT JOIN [Comments] AS [c] ON [p].[Id] = [c].[PostId]
ORDER BY [p].[Id], [b].[Id]

The .ProjectTo<PostDto>() will tell AutoMapper's mapping engine to emit a select clause to the IQueryable that will inform Entity Framework that it only needs to query the fields presents in the DTO.

A common case for the .ProjectTo is using small DTOs/models. For example, we can have a smaller DTO to just return a summary of the posts to list in the frontend, with just the id, name, and comments counts:

public class PostSummaryDto
{
    public int Id { get; set; }
    public string Title { get; set; }
    public int CommentsCount { get; set; }
}

And writing again only 1 line on C#:

var postSummary = await mapper.ProjectTo<PostSummaryDto>(dbContext.Posts, null).ToListAsync();

The SQL code looks really nice:

SELECT [p].[Id], [p].[Title], (
        SELECT COUNT(*)
        FROM [Comments] AS [c]
        WHERE [p].[Id] = [c].[PostId]
    ) AS [CommentsCount]
FROM [Posts] AS [p]

As we can see we can have a very performant query just using 1 line of code. If you want to read more about .ProjectTo please read here.

Configuring BroadLink with SmartIR in Home Assistant

Ignacio laborde — Tue, 05 Apr 2022 16:26:25 +0000

Configure SmartIR is a very simple process but it's not something we do very often, and since I have a very bad memory for this kind of thing I decided to make a quick tutorial.

From SmartIR official doc:

SmartIR is a custom integration for controlling climate devices, media players and fans via infrared controllers.
SmartIR currently supports the following controllers:

Broadlink

Xiaomi IR Remote (ChuangmiIr)

LOOK.in Remote

ESPHome User-defined service for remote transmitter

MQTT Publish service_

Go to Configuration -> Devices & Services (Integrations, devices, entities and areas). And search for the BroadLink integration.
Enter the IP number of the BroadLink remote(you can get the IP easily using the BroadLink app. Select the remote, click on the 3 points in the upper right corner, device info and you will see the IP).
Enter a name and click submit.
Copy the entity id for later.
Add SmartIR to HACS, probably you will not find the integration, so you have to add it manually.
Just click on the Custom repositories option, and use the following link to fill the repository field https://github.com/smartHomeHub/SmartIR (make sure to choose Integration in the category list).
Let's going to configure a climate device. Open your configuration.yml file and add the following block: ```

smartir:

climate:

platform: smartir name: Living AC unique_id: living_ac device_code: 1760 controller_data: remote.rc_living_remote


8.Replace name and unique_id with a value of your choice, device_code with one of the available codes of the [list](https://github.com/smartHomeHub/SmartIR/blob/master/docs/CLIMATE.md#available-codes-for-climate-devices) and controller_data with the entity id of the 4th step.

9.Save the configuration.yml and restart Home Assistant. 

10.Once the restart is completed, add a new card to your view. Click on add card button -> select the Thermostat card, and select the entity. ![configuring Thermostat card](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/z5u9j3j7d4vbkze0x25b.PNG)

**Now you should be able to control your air conditioner in a very simple way.**

### Extra:

_When adding the BroadLink device to Home Assistant could be possible to get an error because the device is blocked, just follow the instructions mentioned below to unlock the device._

![unlock device instructions](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/89ozgwtjkcg6vrwgqnvs.PNG)

Tips for new developers

Ignacio laborde — Mon, 31 May 2021 20:40:06 +0000

When you start in the world of programming you discover that there is too much to learn and at first it can be a bit intimidating. We were all in that place, and the idea is to provide some tips that I learned while going down this road.

Don't grab multiple tasks at the same time

This is one of the most common, you do not find the correct limits of your assignment and end up working on several related tasks at the same time, in the end, you didn't advance in any of them and blocking your teammates.

Be methodological

Much of the daily tasks of devs are repetitive, try to have an order and a methodology. In the beginning, it could be useful to create a list of steps and validate it with your TL or a more experienced dev.

For example, before starting to code a new task:

Check that your base branch is clean
Pull the latest changes
Create the topic branch

Find at least one solution to the problem

When you are a jr dev, nobody expects you to solve everything on your own, and it is very likely that you will be blocked several times with the same task. But before asking for help, try to at least find a solution to the problem, even if it is the worst. Programming is largely troubleshooting, if someone solves everything for you, you won't notice progress very soon. You have to train yourself.

Don't assume

If you have a question about business logic or a block of code, don't assume, it can lead you in the wrong direction. I've been working as a dev for several years and I still usually make that mistake, so try to take it as a habit from the beginning. Better ask than do extra work.

Solve the problem first, then make it beautiful

It is always easier to work on a problem that has already been solved, even if it was done in the worst way. Iterate your code, don't try to find the best solution the first time because you will probably block yourself, make it work, then make it beautiful.

Be open to criticism (valid for experienced devs too)

Our code is a part of us, but we don't always have the best solution, the most performant or whatever, hear the advice, move your ego away, even if you do not agree, it can be of help in the future.

Add logs

Whenever I start a new project I tell myself: "this time start adding logs to everything you do" and clearly I never do. When your code has a problem in production and you don't have much idea what the problem might be, you will hate yourself for not adding logs. Whenever you can, add logging and comments.

Be honest

Please be honest about your knowledge, especially in interviews. If you can't answer the basic questions of a tech/concept, don't add it to your resume. Instead of including something that barely knows because you thought you knew it just by having read/heard something, in the interview, you can say: "I've been reading about...but never worked or did a PoC...".

Probably there are more tips and advice for novice devs, if you have more ideas feel free to leave a comment.

Building a workflow for your ASP.NET Core app with Github Actions

Ignacio laborde — Wed, 12 May 2021 23:33:32 +0000

For this example, I merged two workflows provided by GitHub: .NET and Deploy to Amazon ECS. The idea is build a simple workflow like this:

Why Github Actions?

Github Actions offers workflows that can build the code in your repository and run your tests. Workflows can run on GitHub-hosted virtual machines, or on machines that you host yourself.

To start with Actions, create a new file in the .github/workflows directory named api-deployment.yml and copy the following YAML:

name: API workflow

on:
  push:
    branches: [ main ]
    paths:
      - 'src/**'    
  pull_request:
    branches: [ main ]
    paths:
      - 'src/**'

jobs:
  build:
    name: Build API
    runs-on: ubuntu-latest
    env:
      working-directory: './src'
    steps:
    - uses: actions/checkout@v2
    - uses: actions/setup-dotnet@v1
      with:
        dotnet-version: '3.1.x'
    - name: Restore dependencies
      run: dotnet restore API.sln
      working-directory: ${{env.working-directory}}
    - run: dotnet build --no-restore
      working-directory: ${{env.working-directory}}    
    - run: dotnet test --no-build --verbosity normal
      working-directory: ${{env.working-directory}}

  deploy-dev:
    name: Deploy to Dev
    if: github.event.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    needs: [build]

    steps:
    - name: Checkout
      uses: actions/checkout@v2

    - name: Configure AWS credentials
      uses: aws-actions/configure-aws-credentials@v1
      with:
        aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
        aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
        aws-region: us-east-2

    - name: Login to Amazon ECR
      id: login-ecr
      uses: aws-actions/amazon-ecr-login@v1

    - name: Build, tag, and push image to Amazon ECR
      id: build-image
      env:
        ECR_REGISTRY: ${{ steps.login-ecr.outputs.registry }}
        ECR_REPOSITORY: your-ecr-name
        IMAGE_TAG: ${{ github.sha }}
      run: |
        # Build a docker container and
        # push it to ECR so that it can
        # be deployed to ECS.
        docker build -f src/api/Dockerfile -t $ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG src/api
        docker push $ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG
        echo "::set-output name=image::$ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG"

    - name: Fill in the new image ID in the Amazon ECS task definition
      id: task-def
      uses: aws-actions/amazon-ecs-render-task-definition@v1
      with:
        task-definition: .github/task-definitions/your-api-task-definition.json
        container-name: your-container-name
        image: ${{ steps.build-image.outputs.image }}

    - name: Deploy Amazon ECS task definition
      uses: aws-actions/amazon-ecs-deploy-task-definition@v1
      with:
        task-definition: ${{ steps.task-def.outputs.task-definition }}
        service: your-service-name
        cluster: your-cluster-name
        wait-for-service-stability: true

That is quite a long file, so let's start to dissect the most important lines.

Events

An event is an activity that triggers a workflow. To define the event (or events) we use the on keyword. Also, you can add constraints over those triggers.
Here we are setting that our action is going to be triggered on every push or pull request to main, and at least one modified file matches the configured paths.
Note: push and pull_request events support paths and paths-ignore filter, for more info read here

on:
  push:
    branches: [ main ]
    paths:
      - 'src/**'    
  pull_request:
    branches: [ main ]
    paths:
      - 'src/**'

Jobs

A job is a set of steps that execute on the same runner. By default, a workflow with multiple jobs will run those jobs in parallel.

Build

Build is just a name for this job, you can set whatever you want. Here I'm using mostly the example from the .NET workflow. Will restore dependencies, build the code and run the unit tests.

  build:
    name: Build API
    runs-on: ubuntu-latest
    env:
      working-directory: './src'
    steps:
    - uses: actions/checkout@v2
    - uses: actions/setup-dotnet@v1
      with:
        dotnet-version: '3.1.x'
    - name: Restore dependencies
      run: dotnet restore API.sln
      working-directory: ${{env.working-directory}}
    - run: dotnet build --no-restore
      working-directory: ${{env.working-directory}}    
    - run: dotnet test --no-build --verbosity normal
      working-directory: ${{env.working-directory}}

Deploy-dev

Deploy-dev job is using the Github workflows templates,
an upcoming post will cover how to create this infrastructure in detail to complete a full deployment.
But I want to highlight the following block:

  deploy-dev:
    name: Deploy to Dev
    if: github.event.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    needs: [build]

Using the needs keyword we define a dependency to the previous job build, only if the build was successfully completed this job is going to be executed. In that form, we change the default behavior of running the jobs in parallel to run sequentially.

On the other way, the if conditional allows avoiding the execution of a job unless a condition is met.
Here we use the github context to get the branch that is triggering the workflow, if the branch is "main" means that the PR was merged, so we can complete our deployment to our dev environment.

So that's it!

You can find a public repo with the example here