Domain Driven Design with Web API revisited Part 11: database creation and initial tests

Introduction

In the previous post we created the load test specific database context in a new repository layer. We also implemented the abstract timetable repository interface.

In this post we’ll create the database and fill it up with some initial values. The purpose of this post and the next is to see how our domain layer is reflected in the data store and to discover potential shortcomings and errors. I want to avoid the situation where we come to the final post where we test the web service layer and nothing works as it should. The tester application will be a simple C# console application.

Read more of this post

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

Python language basics 45: 3 ways to copy a list

Introduction

In the previous post we discussed how to slice a collection. We saw how you could create another collection from the original by extracting a range of it.

In this post we’ll describe various ways to create a copy of a list.

Read more of this post

Python language basics 44: slicing a list

Introduction

In the previous post we looked at the index function for collections. We saw how it helped find the location of an object by returning the position as an integer.

In this post we’ll look at how to slice a list.

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.

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.