Becoming a software developer – episode XI

Becoming a software developer – episode XI

Welcome to the eleventh episode of my course “Becoming a software developer” in which we will use AutoMapper library, implement simple HTTP POST method and use asynchronous methods.

All of the materials including videos and sample projects can be downloaded from here.
The source code repository is being hosted on GitHub.


 

Scope

  • AutoMapper
  • HTTP POST
  • Async

Abstract

AutoMapper

As programmers, we want to simplify and automate as many things as possible. One of such activities might be transforming object of type A into B, for example User into UserDto. For sure, we can do it in a naive way, like this:

We can also do it in a better way, by extracting IMapper interface, for example:

Eventually, we can use external library, like AutoMapper which allows for a quick object mapping, as well as provides a rich configuration and settings.

HTTP POST

In order to create a new resource (for example user), we should create a new endpoint that supports HTTP POST operation. As the documentation states, POST is responsible for doing exactly this (unlike the GET for fetching the data or PUT for updating it). It’s very trivial to add the new HTTP POST endpoint within ASP.NET Core controller – just mark with the attribute HttpPost, provide a route path if needed and make sure to include FromBody attribute within a method parameter in order to bind incoming request to the defined type.

Async

When it comes to I/O (In/Out) operations, we should strive for making them asynchronous always when it’s possible. There’s no point to spend the valuable server resources and keep it busy only to wait till some external database or web service call finishes. This is why the asynchronicity was introduced in a first place. Perform a request, get a Task object in return and await it when you need the result of such operation. We will apply this pattern to our repositories, services and controllers.

Next

In the next episode, we’ll talk about HTTP Status Codes, Headers and write first unit and integration (end-to-end) tests.

2 Comments Becoming a software developer – episode XI

  1. Pingback: Dew Drop - April 6, 2017 (#2457) - Morning Dew

  2. 0xmarcin

    “When it comes to I/O (In/Out) operations, we should strive for making them asynchronous always when it’s possible”. That would be true if async/await come without any additional costs. Unfortunatelly using async/await will make your code less readable, for example compare method delcarations:

    User FindUserByEmail(string email);

    and

    async Task FindUserByEmailAsync(string email);

    I hope you agree that the second declaration comes with a lot of visual noise and is less readable. But poorer readablity is not the only cost of async/await, also exception stacktraces are much more complicated than in synchronous case (and yes I know about https://github.com/benaadams/Ben.Demystifier – this only proofs my point how bad async stacktraces are). And the last but not least, if you are using async/await you should know about ConfigureAwait(false) and possibilities of deadlocks – this puts more pressure on novice programmers. Asynchronous programming was always considered an advanced topic and requires extra care when applied to line of business apps.

    Saying all this, I must admit that async/await has its usages but in a typical business application (util you say serve images like Flickr or write some pice of infrastructure code) this is just another type of premature optimization on project-wide scale. I would much more rather start with sync code and then rewrite these parts that do a lot of IO but only when confirmed that they are the bottleneck after use of profiling tools. From my experience typical business apps performace trobles are mostly centered on database and here using async/await gain you nothing.

    On the other hand MS does not help here and often forces us to use async, for example HttpClient has only Async API.

    Opss, looks like my commend really grow. I really would like to hear from you what do you think about my arguments.

    Reply

Leave A Comment

Your email address will not be published. Required fields are marked *