Continuation tasks in .NET TPL: a simple continuation example

Tasks in .NET TPL make it easy to assign tasks that should run upon the completion of another task.

We’ll need a basic object with a single property:

public class Series
{
	public int CurrentValue
	{
		get;
		set;
	}
}

Declare a task that increases the CurrentValue in a loop and return the Series. This task is called the antecedent task.

Task<Series> motherTask = Task.Factory.StartNew<Series>(() =>
{
	Series series = new Series();
	for (int i = 0; i < 10000; i++)
	{
		series.CurrentValue++;
	}
	return series;
});

Declare the continuation task where we also use the antecedent as method parameter:

motherTask.ContinueWith((Task<Series> previousTask) =>
{
	Console.WriteLine("Final Balance: {0}", previousTask.Result.CurrentValue);
});

The antecedent task will then schedule the continuation task for you. If there are other tasks then they may run before or after the continuation tasks depending on the task scheduler.

View the list of posts on the Task Parallel Library here.

An example of using the dynamic keyword in C# .NET

The dynamic keyword in C# is similar to Reflection. It helps you deal with cases where you’re not sure of the concrete type of an object. However, you may expect the object to have a certain method that you can invoke at runtime. E.g. you have a framework that external users can write plugins for. You may set up a list of rules for the plugin to be valid, e.g. it must have a method called “Execute” and a property called “Visible”.

There are various ways you can solve this problem and one of them is dynamic objects. Using the dynamic keyword will turn off the automatic type checking when C# code is compiled. The validity of the code will only be checked at runtime.

Read more of this post

Domain Driven Design with Web API revisited Part 18: tests and conclusions

Introduction

In the previous post we continued working on our Web API 2 layer and added two new controller actions: POST which handles both updates and insertions and DELETE which is responsible for deleting load tests. Our first draft of the DDD load testing demo is actually finished at this point. All that’s left is testing the POST and DELETE functions of the Web API.

We’ll do that in this post. We’ll also write some conclusions.

Read more of this post

How to terminate a .NET console application with an exit code

It happens that you’d like to terminate a .NET console application with some exit code. Normally exit codes are integers where negative numbers indicate that something has gone wrong with -1 being the most common. Positive digits and zero on the other hand usually imply a program execution with no errors. The most common positive exit codes are 0 and 1.

Read more of this post

Domain Driven Design with Web API revisited Part 17: the POST and DELETE controller actions

Introduction

In the previous post we started building the top layer of our load testing DDD demo solution. We added an empty Web API 2 project and also created a GET controller action to retrieve the open load tests 2 weeks ahead. We also managed to add an IoC controller called StructureMap which injects the required concrete dependencies into the controllers and service methods.

In this post we’ll continue building on our demo project and add the POST and DELETE controller actions as well. We’ll also see another application of the view-model concept we saw earlier.

Read more of this post

Design patterns and practices in .NET: the Strategy Pattern

Introduction

The strategy pattern is one of the simplest patterns to implement. Have you ever written code with ugly if-else statements where you check some condition and then call another method accordingly? Even worse: have you written if-else statements to check the type of an object and then called another method depending on that? That’s not really object-oriented, right? The strategy pattern will help you clean up the mess by turning the if statements into objects – aka strategies – where the objects implement the same interface. Therefore they can be injected into another object that has a dependency of that interface and which will have no knowledge of the actual concrete type.

Read more of this post

Design patterns and practices in .NET: the Factory Patterns – concrete, static, abstract

Introduction

Factories are extremely popular among design patterns. I have never seen any reliable statistics on the usage of patterns but factories must be among the top three most used patterns. However, that is not to say that they are used correctly. Many developers misunderstand factories to factor out chunks of code to other classes where the factored-out code is encapsulated into a static method as follows:

double cost = CostFactory.Calculate(input params);

Read more of this post

Domain Driven Design with Web API revisited Part 16: the Web API consumer layer and the GET controller action

Introduction

In the previous post we built the concrete application service layer for our demo project. We saw that it was quite straightforward to implement the abstract service we inserted in the post before that.

It is time to build the top layer of the solution which will communicate with the application service. This post will be quite technical as we need to add an IoC container to the Web API project.

Read more of this post

The portable Web API client library

I this short post I just would like to draw your attention to a portable Web API client library available from NuGet. You can use it in multiple project types, like console and Window Phone apps where you need to perform HTTP-related actions.

The library is available from within Visual Studio in the NuGet package manager:

Web API client library in NuGet

From then on you can use the HttpClient object from the System.Net.Http namespace to initiate HTTP calls, e.g.:

HttpClient client = new HttpClient()
{
	BaseAddress = new Uri("http://www.myapi.com/")
};
HttpResponseMessage response = await client.GetAsync("customers");

Domain Driven Design with Web API revisited Part 15: the concrete application service

Introduction

In the previous post we looked at application services in general. We saw that they connect the ultimate consumer layer, such as MVC with the domain layer. They have no or very little logic. Instead, they act as coordinators. They accept requests from the consumer layer and make sure that the consumer layer gets back a valid response. The consumer won’t care how the application service carries out its job and what concrete dependencies it may have.

In this post we’ll build upon the abstract timetable service and basic messaging classes. The goal is to build a functioning service layer.

Read more of this post

Elliot Balynn's Blog

A directory of wonderful thoughts

Software Engineering

Web development

Disparate Opinions

Various tidbits

chsakell's Blog

WEB APPLICATION DEVELOPMENT TUTORIALS WITH OPEN-SOURCE PROJECTS

Once Upon a Camayoc

ARCHIVED: Bite-size insight on Cyber Security for the not too technical.