Introduction

This is part 4 of this series which I don’t know when it will ends :o). In part 3 I started to to explore the Core of KiGG. In this part we are still inside the core, but we are going further deep to have a look inside the infrastructure.

I’m going to talk about infrastructure for the next couple of posts or maybe more. Because actually it contains the heart of KiGG. For me this is a really interesting topic, it is kind of like a hobby but whereas other people like swimming or playing Poker Online, I like investigating infrastructures. I hope that you find what I write interesting and informative.

More...

Introduction

In part 2, we explored KiGG project structure. I gave a short brief and summary about each project in the solution. And briefly discussed the relation between them.

In this part we are going to start going much deeper. Staring with the Core, and this might take several parts by itself as the Core is huge and contains lots of stuff that worth to be discussed.

More...

Introduction

In part 1 I talked about KiGG high level architecture. In this part I am going to talk about KiGG project structure and summarize the purpose of each project in the solution. I’ll not go into deep details of each project. I’ll save that for some other posts, just be patient with me and stay tuned.

More...

Introduction

In this multi part series I am going to explore KiGG design and architecture as well as projects structures.

At the beginning I would like to give a brief about KiGG History.

About KiGG

KiGG is similar to DotNetKicks, Digg and DZone. However it much closed to DotNetKicks and way smaller than DZone. KiGG was founded by Kazi Manzur Rashid and first introduced in his article on DotNetSlackers.com: Kigg - Building a Digg Clone with ASP.NET MVC, that was on Feb 2008. It was built with First ASP.NET MVC preview.

In early this year 2009 on January, Rashid was almost done with KiGG, however ASP.NET MVC 1.0 was not released yet. At this time Rashid announced DotNetShoutout.com as first live application based on KiGG. On March 2009 Rashid released version 2.2 of KiGG after the release of ASP.NET MVC 1.0.

I joined the team on April and start working with Entity Framework implementation for KiGG as well as supporting the project.

Thank you Rashid for giving me this opportunity.

More...

I had few previous posts about DDD & TDD with Entity Framework that you might need to return to them before you proceed with this post. To summarize these posts, I was trying to build testable Models that is based on EF. But EF doesn't support Persistence Ignorance in its first version which make testing it in most cases require a database connection where you can test you code against it. My target was to build a testable models based on EF and that is independent of any underlying data source.

Introduction, Domain Model Review:

More...

I decided to provide some integration testing before proceeding as a proof of concept. In integration testing I will connect to the database and perform unit testing while connecting to the database.\

This unit test is almost identical to the one in my previous post. Except here I am testing the results that is coming out from EF and Database.

My target is to test IDataContext Implemented methods in NorthwindDataContext. Find below the Integration unit testing class. More...

In return to my previous posts about DDD & TDD with EF. I discovered few catches in my design that I wished to high light and discuss in this post. To summarize my take here are the head lines:

• What is the Responsibility of ObjectContext in EF?
• What is the Responsibilities of Repositories and whether they should be coupled with EF or not?

I come up with this post after few discussions through e-mail with Davy Landman.

More...

In previous post I talked about building domain model for Northwind using Entity Framework. I used the generated ObjectContext class which is NorthwindDataContext as the basic Data Access Layer Helper. But my NorthwindDataContext is implementing custom interface I created in order to be able to make my Data Access Layer testable as well as to be independent from EF.

My target is to achieve decoupling between EF and all layers above it. This include Repository classes. This might not be of a big benefit to everyone, because my repositories implementation will still dependent on IDataContext. But for me it will help to do TDD more smoothly regardless of my underlying data access layer. Beside it might allow me in future to be able to switch from EF to LINQ to SQL and just implement my IDataContext interface for LINQ to SQL.

Source code is attached to this post, feel free to download it and explore the code

More...

Introduction:

In my previous post I talked about definitions of TDD as specified in different sources. Here in this post I'll walk-through applied Domain Driven Design & Test Driven Design on Entity Framework.

I assume that you already know Entity Framework and how to create your entity data modes using Visual Studio.Net 2008 with SP1.

Domain Driven Design & Entity Framework:

To simplify things, I am using Northwind database. Basically I'll expose 3 tables in this database, Categories, Products & Suppliers. Those will be my domain objects as Category,Product and Supplier classes.

Each Category object might contain one or more items of Product. Same thing for Supplier object as it might provide one or more items of Product. That means Product object must have a Supplier and a Category. I defined those criteria for my Domain Objects.

More...