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


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

Python language basics 43: find the position of an element in a collection


In the previous post we looked at how to remove elements from a collection in Python. We discussed the del keyword and the remove function. The del keyword works based on indexes whereas the remove function accepts the object to be removed.

In this post we’ll look at the index function which helps us locate an element in a collection.

Read more of this post

Python language basics 42: 2 ways to remove elements from a collection


In the previous post we looked at a couple of ways to insert or append elements to a collection. We saw the usage of the insert, append and extend functions. We also discussed how the + and += operators affect a list.

In this post we’ll look at the exact opposite, i.e. how to remove an item from a collection.

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


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

Using isolated storage for application-specific data in C# .NET Part 2: directories

In this post we briefly went through the basics of isolated storage files. We saved some applications settings in a text file within the isolated storage reserved for an application at the user level.

We’re not restricted to save files in isolated storage. We can also create folders for organisation purposes. It’s very easy to create a folder. The IsolatedStorageFileStream example is almost identical to what we saw in the post referenced above. However, remember that the directory must be created first before you can save anything in it:

private static void SaveSettingsInIsoStorage()
	IsolatedStorageFile applicationStorageFileForUser = IsolatedStorageFile.GetUserStoreForAssembly();
	IsolatedStorageFileStream applicationStorageStreamForUser = new IsolatedStorageFileStream("AppSettings/settings.txt", FileMode.Create, applicationStorageFileForUser);
	AppSettings settings = new AppSettings()
		Job = "Programmer",
		Language = "C#",
		Name = "Andras"
	string contents = JsonConvert.SerializeObject(settings);

	using (StreamWriter sw = new StreamWriter(applicationStorageStreamForUser))

It can be a good idea to check whether the directory exists before you create it:

string[] directoryNames = applicationStorageFileForUser.GetDirectoryNames("AppSettings");
if (!directoryNames.Any())

Read the next part here.

Read all posts dedicated to file I/O here.

Using isolated storage for application-specific data in C# .NET Part 1: the basics

There’s a special storage location for a .NET application on Windows that is allocated to that application. It’s called isolated storage and it’s an optimal place to store files by an application that doesn’t have full access to the file system. Writing to and reading from isolated storage doesn’t require any extra security check. An application without full access to the file system will be able to use its allocated slot in isolated storage and nothing else. It’s an ideal mechanism for storing e.g. application state.

However, don’t confuse isolated storage with file security. It is still a “normal” location on disk with a file path. A typical location is under users/[username]/appdata/local. Therefore you or full-trust applications can still find and modify the files saved in isolated storage. However, limited-trust applications won’t be able to access any other part of the file system.

Read more of this post


A great site

iReadable { }

.NET Tips & Tricks

Robin Sedlaczek's Blog

Love to use Microsoft Technologies

A Good Blog is Hard to Find

Living in a HarsH ReaLiTy

Ricos Blog zu Softwaredesign- und architektur

Ideen und Gedanken rund um Softwaredesign und -architektur, Domain-Driven Design, C# und Windows Azure

the software architecture

thoughts, ideas, diagrams,enterprise code, design pattern , solution designs

Technology Talks

on Microsoft technologies, Web, Android and others

Software Engineering

.NET, SQL and Mobile

Disparate Opinions

Various tidbits

chsakell's Blog

Anything around ASP.NET MVC,WEB API, WCF, Entity Framework & C#

Cyber Matters

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

Guru N Guns's

OneSolution To dOTnET.

Johnny Zraiby

Measuring programming progress by lines of code is like measuring aircraft building progress by weight.


Get every new post delivered to your Inbox.

Join 769 other followers

%d bloggers like this: