Domain Driven Design with Web API extensions part 12: seeding the MongoDb database

Introduction

In the previous post we constructed the database objects that represent the database version of the load testing domain objects. Recall that there’s no automated code generation and mapping tool for MongoDb .NET – at least not yet. Therefore decoupling database and domain objects with MongoDb as the backing store usually means some extra coding but in turn you’ll have completely independent database and domain objects.

We also inserted an abstraction and a concrete implementation for the connection string repository.

In this post we’ll seed the database with the same initial values as we had for the EF data store.

Read more of this post

Domain Driven Design with Web API extensions part 11: the MongoDb database objects

Introduction

In the previous post we mainly discussed the advantages and limitations of coding against MongoDb using .NET. We also discussed the MongoDb context a little bit and started building the MongoDb version of the repository. We said that there’s not much automation available in the .NET MongoDb driver compared to what you get in EF. However, that’s not necessarily a bad thing since you’re not tied to some “secret” and “magic” underlying mechanism that does a lot of work in the background. Instead you’re free to implement the objects, the rules, the conversions etc. as you wish. It usually means more code, but you get absolute freedom for your repository implementation in return.

In this post we’ll first add a new element to the common infrastructure layer. Then we’ll add the MongoDb database representation of our domain objects.

Read more of this post

Domain Driven Design with Web API extensions part 10: the MongoDb context

Introduction

In the previous post we installed MongoDb locally. We also started the MongoDb server and connected to it with a client. We then inserted a test console application into our DDD skeleton project, imported the MongoDb .NET driver and connected to the MongoDb server using the driver.

In this post we’ll continue to explore the MongoDb context and some practical limitations compared to the automated tools available in EntityFramework. We’ll also add a new C# console library to the DDD skeleton project. The new library will eventually contain the MongoDb equivalent classes of what we have in the WebSuiteDemo.Loadtesting.Repository.EF layer.

Read more of this post

Domain Driven Design with Web API extensions part 9: setting up MongoDb

Introduction

In the previous post we set out the main topic of this new extension to the DDD model project. We said that we would add another repository mechanism, namely MongoDb. We went through the basic idea and some terminology behind MongoDb, e.g. what a document, a collection or an object ID means.

In this post we’ll set up MongoDb locally and try to connect to it from .NET using the MongoDb .NET driver.

Read more of this post

Domain Driven Design with Web API extensions part 8: domain repository with MongoDb

Introduction

Some months ago we went through an updated series on Domain Driven Design starting with this post. We built a functioning skeleton project with EntityFramework as the backing store, a Web API layer as the top consumer, a loosely coupled service layer and a central domain layer with some logic.

In this extension series we’ll investigate how to implement the domain repository in a data store that’s markedly different from SQL Server. In particular we’ll take a look at the NoSql document-based MongoDb.

Read more of this post

Domain Driven Design with Web API extensions part 1: notifications

Introduction

A couple of weeks ago we went through an updated series on Domain Driven Design starting with this post. We built a functioning skeleton project with EntityFramework as the backing store, a Web API layer as the top consumer, a loosely coupled service layer and a central domain layer with some logic.

In this extension series we’ll investigate a couple of ways to add various dependencies to the project. In particular we’ll look into how to send email notifications in case a new load test has been booked.

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");

Web API 2 security extensibility points part 1: starting point and HTTP request context

Introduction

Web API 2 comes with a number of new security features. In this new series we’ll concentrate on the HTTP request context and its Principal property. In particular we’ll see how to hook into the different extensibility points in the Web API. These extensibility points offer you to plug in your security-related checks at different points in the application lifetime when a request hits your API. You can carry out a number of checks and modify the request Principal according to your business rules and needs.

I’m building the demo in Visual Studio 2013. I’m not sure at this point how much the Web API template will change in Visual Studio 2015.

Read more of this post

Building a Web API 2 project from scratch using OWIN/Katana .NET Part 3: hosting on Helios

Introduction

In the previous post we discussed how to use OWIN host to self-host a Web API 2 application. We saw how easy and straightforward it was to install the OWIN hosting package with NuGet.

In this post we’ll look at another hosting option: Helios.

Read more of this post

Building a Web API 2 project from scratch using OWIN/Katana .NET Part 2: OWIN host

Introduction

In the previous post we saw how to build a simple Web API from scratch using a couple of OWIN/Katana components. We added a couple of Katana libraries from NuGet, wired up the routing from the Startup class and we were good to go.

In this post we’ll see one way to make the application run independently of IIS. As we stated before an important benefit of this new OWIN infrastructure is that you can make your ASP.NET web application run on multiple hosts, not only IIS. IIS is only one of the options.

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

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