Using the BlockingCollection for thread-safe producer-consumer scenarios in .NET Part 3

In the previous post of this mini-series we started building our model for the producer-consumer scenario. We have two objects to begin with. First, WorkTask.cs which represents the task that’s added to the work queue by the producers and retrieved by the consumers to act upon. Second we have an object, WorkQueue to encapsulate the work queue itself. It will be the consumer of the work queue through the MonitorWorkQueue method.

We haven’t yet seen the the consumer class yet. We’ll do that in this post.

Read more of this post

Using the BlockingCollection for thread-safe producer-consumer scenarios in .NET Part 2

In the previous post we briefly went through the producer-consumer scenario in general. We also mentioned another class in the System.Collections.Concurrent namespace that we haven’t seen before, i.e. the BlockingCollection of T.

We’ll start looking into this object in this post.

Read more of this post

Domain Driven Design with Web API revisited Part 10: the load test database context

Introduction

In the previous post we started building our EntityFramework repository layer. In particular we worked on the overall WebSuite database context which is meant to be an overall DB context object for all bounded contexts in the WebSuite application. It can be beneficial for each bounded context to have its own matching DB context so that it can concentrate on its DB-related tasks without interfering with other bounded contexts.

In this post we’ll build the load test DB context. This is also where we’ll implement the abstract repository interface we added earlier to the Domain layer.

Read more of this post

Using the BlockingCollection for thread-safe producer-consumer scenarios in .NET Part 1

We’ve looked at the 4 concurrent, i.e. thread-safe collections available in .NET:

We also mentioned that 3 of these, i.e. the concurrent queue, bag and stack implement the generic IProducerConsumer interface. They can be used in producer-consumer scenarios where one or more threads write to a work queue. They are the producers in the setup. One or more other threads then read from the same work queue in order to perform some task on them. These are the consumers. When the consumer takes an item from the work queue then that item is also removed from it so that it’s not processed more than once. If you need to build a scenario like that then you’ll obviously need thread-safe collections that can synchronise access to them in a reliable manner.

We haven’t seen before how a producer-consumer scenario can be built from scratch using the available classes in the System.Collections.Concurrent namespace. We’ll do that in this and the next couple of posts.

Read more of this post

Domain Driven Design with Web API revisited Part 9: the overall database context

Introduction

In the previous post we looked at the repository pattern and abstract repositories in general. We discussed the role of repositories and saw how they can be useful in hiding the implementation details of the concrete data store solution. Repositories are great at limiting direct access to the data store from other layers of the application. They force external callers to go through the domain and its logic when performing data access related operations.

In this post we’ll start implementing the repository for our aggregate root, i.e. the Timetable object. There’s a lot of ground to cover so the topic will span two posts. We won’t create the database yet. That is the subject of another post that follows upon completing the concrete repository layer. The following several posts will be quite technical in nature as opposed to what we’ve seen so far.

Read more of this post

How to hide the text entered in a .NET console application

You’ve probably encountered console applications that ask for a password. It’s very likely that the password will stay hidden otherwise other people viewing your screen can easily read it.

This short post will present a possible solution on how to achieve a hidden string input in a .NET console application.

Read more of this post

Using isolated storage for application-specific data in C# .NET Part 4: various

In the previous post we looked at how to find the location of a file when stored in isolated storage. We saw that isolated storage files have also a “normal” file path that you can navigate to in file explorer. The file paths are difficult to guess as they have complicated names but they are not secured in any way.

In this post we’ll briefly look at some various other things about isolated storage mainly related to size and quota.

Every application that uses isolated storage has a defined quota in bytes that it can use. Normally the default quota for partially trusted applications, e.g. those that you download from the internet, is 1MB. The IsolatedStorageFile object exposes a couple of properties that describe the quota, the available space and the size used:

IsolatedStorageFile applicationStorageFileForUser = IsolatedStorageFile.GetUserStoreForAssembly();
			
Debug.WriteLine(applicationStorageFileForUser.AvailableFreeSpace);
Debug.WriteLine(applicationStorageFileForUser.Quota);
Debug.WriteLine(applicationStorageFileForUser.UsedSize);

If the quota is not enough you can request a new upper limit using the IncreaseQuotaTo method of the IsolatedStorageFile class:

bool quotaIncreaseSuccess = applicationStorageFileForUser.IncreaseQuotaTo(some number);

The method will throw an exception if you’re trying to reduce the quota, i.e. set a lower number than the current quota.

Read all posts dedicated to file I/O here.

Domain Driven Design with Web API revisited Part 8: the abstract repository

Introduction

In the previous post we finished working on our domain layer. We have built the aggregate root of our load test aggregate, i.e. the Timetable object. It is meant to act as an umbrella for Loadtest-related operations. We can also consider it as a domain service. External callers that wish to interact with load tests must do so through the Timetable object.

However, that is not the entire story as far as data storage is concerned. In this post we’ll start discussing repositories.

Read more of this post

Using isolated storage for application-specific data in C# .NET Part 3: storage location

In this post we looked briefly at how to work with directories in isolated storage. In this post we’ll look at where isolated storage files are saved on disk depending on the isolation type: by user or by machine.

Recall our code to save the program settings specifically for the user:

Read more of this post

Domain Driven Design with Web API revisited Part 7: the aggregate root in our domain model

Introduction

In the previous post we discussed the concept of associations and standalone classes. We saw why it was important to keep the coupling between domain objects at a minimum. We also built the central object in our load test domain, Loadtest.cs.

In this post we’ll take a step upwards and discuss the root of the load test aggregate.

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.