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

Advertisements

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

A great WordPress.com site

Elliot Balynn's Blog

A directory of wonderful thoughts

Robin Sedlaczek's Blog

Developer on Microsoft Technologies

HarsH ReaLiTy

A Good Blog is Hard to Find

Softwarearchitektur in der Praxis

Wissenswertes zu Webentwicklung, Domain-Driven Design und Microservices

the software architecture

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

Technology Talks

on Microsoft technologies, Web, Android and others

Software Engineering

Web development

Disparate Opinions

Various tidbits

chsakell's Blog

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

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.

%d bloggers like this: