Moses' Blog

KiGG Design And Architecture – Part 1 The high level design

mosessaur — Sat, 14 Nov 2009 14:13:22 PST

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.

High Level Architecture

The below picture shows high level architecture of KiGG as I view it and tried to simplify it.

Figure 01- KiGG high level design

As the diagram describes, KiGG consists of 6 main artifacts, Infrastructure, Domain Model, Repositories, Services, Presentation and IoC/DI.

This is not the best design, and the design contains many sections in which we can tweak and tackle to provide better improved design. I am going to give a brief about each of these major artifacts.

1. Infrastructure

Contains definition and contracts for KiGG infrastructure. This includes logging, caching, event aggregator, background tasks, bootstrapper, etc… IoC/DI is also considered part of the infrastructure.

2. Domain Model

Domain models are KiGG entities such as participant users, stories, comments etc. Domain models are shared across and used by all artifacts as shown in the diagram. But models itself do not use any of these artifacts.

3. Repositories

Core data access definition. KiGG came with 2 repository implementation, first one based on LINQ to SQL, and the second is Entity Framework which support multiple database engine. Currently works KiGG works with SQL Server and MySQL. Repositories interacts with infrastructure to gain benefits of logging, caching and IoC.

4. Services

Contains different types of services such as story weight calculator, spam calculator, firing system events such as story published or submitted events etc… Services interacts with repositories and infrastructure. However it is not a rule that each repository has a service in services component.Services might also contain few background tasks.

5. Presentation

Presentation is implemented using ASP.NET MVC 1.0 with jQuery as scripting and AJAX framework. Presentation access infrastructure, services and repositories through IoC. This layer also has its own presentation domain models (View Data). Http modules and handlers also implemented in this component,

Conclusion

This is KiGG very high level design that shows core artifacts and high level communication between them. I can call bird’s eye view on KiGG from sky.

This is not the best design as I mentioned earlier, however we might refine it later when we move to .Net 4.0.

Entity Framework 4.0 Beta 1 Sneak Peak Session at DotNetWork User Group in Cairo, Egypt

mosessaur — Mon, 05 Oct 2009 07:05:31 PDT

Introduction

Again I was honored to present a talk on first Egyptian .Net user group “DotNetWork”. My previous session -the first- was a joint session with Bishoy Ghaly about Entity Framework v1 in .Net 3.5 SP1. This session was about Entity Framework 4.0.

After we introduced Entity Framework to Egyptian community, I decided to give them a sneak peak at the new version of it. Comparing between both versions, showing the evolution and the massive enhancement made on the new version. The session covered the early CTP 1 of Entity Framework 4.0 Beta 1 that is released last June.

Presentation is available to download here.

Audiences

The main targeted audiences of this talk those who already had their hands on Entity Framework before. Those who experienced current version of Entity Framework on a way or another. And I would give my session level 200. So attending the first session in which we introduced Entity Framework was the least requirement for those who don’t know Entity Framework. Plus give it some hands on code to see what Entity Framework looks like.

The real audiences were totally something different. Few of them attended the first session. And I can sense that they didn’t really practice Entity Framework enough to know it well.

Part of the audiences were already didn’t know what’s ORM –probably students-! Some others where having their very first time to see what is Entity Framework and what it can do.

To be honest, to satisfy this kind of audiences is very hard! And I really hope that I was able to deliver as much as I can about what is Entity Framework, what it can do and comparing between current version and upcoming one.

Session Agenda

My agenda for the session was in the following sequence:

What’s new in Entity Framework 4.0 at glance
Designer enhancements
Deferred loading Vs Explicit loading
Persistence Ignorance support {POCO} (CTP 1)
Code Generation Customizing with T4 templates
Code Only support in EF 4.0 (CTP 1)
Self tracking entities support in EF 4.0 (CTP 1)
Model functions in EF 4.0 (Optional and trimmed for the time)

On the following I’m going to give a summary about my talk on each topic on the above agenda.

What’s new in Entity Framework 4.0 at glance

In this topic a comparison between current version of Entity Framework and vNext of Entity Framework was important. I talked about designer enhancements in general such as Pluralization & Singularization, support complex types and support for stored procedure mapping through the designer. I highlighted to the audiences how this was a problem in current version of Entity Framework and talked about where exactly the issues resides and how Entity Framework 4 Designer in VS.NET 2010 is going to solve these issues making development with Entity Framework more productive.

I also gave a hint about new APIs enhancements and additions which ease the development and testability of Entity Framework.

Other general overview and highlights about T4 templates and code generation customization, support of POCO, model first, code only etc…

This part of the session was just glance overview about some of the new stuff introduced in Entity Framework.

Designer Enhancements

Demos starts from here, people love to see things in action. So I demonstrated practically how Pluralization & Singularization works. And of course showed them how I am happy that I got this in EF4 as it wasn’t presented in current version.

Then the magic of refactoring to complex type! Sadly I was able to show them the magic, but couldn’t show them why this is magic by showing them practically that it will require us to modify the XML to add the complex type and do the mapping to get the job done on current version of Entity Framework.

Next demo was about mapping stored procedures to complex types! Another big improvement in Entity Framework.

Also showed them that updating model from database won’t erase manual modifications to entities! this is also was one of the limitation in current version which I highlighted.

There was another demo in this topic that I skipped for time. It was about Improvements in mapping insert,update & delete operations to stored procedure through Entity Framework designer. I just highlighted the difficulties in current version and told them that this is no more limitation and it is easy and straight forward to be done.

Deferred Loading Vs Explicit loading

One important topic raised since Entity Framework released. On of the demanded features was the support of deferred loading.

We didn’t go through eager loading, because it was one of the topics introduced on first session about EF, to save time I didn’t present it here.

I explained how explicit loading works in Entity Framework. Also introduced new explicit loading API in ObjectContext class which is LoadProperty method.

Then I explained what does deferred loading mean. And by examples and demos they recognized how this should work.

To this point I guess I spent 1 hour and 30 minutes. Between different demos and presentation slides.

Persistence Ignorance Support {POCO}

I started the session with a question! Does anybody know what is Persistence Ignorance mean! The general answer was NO. I already prepared myself to give a very short brief about Persistence Ignorance and the term POCO.

However I had a feeling that they didn’t recognize the benefit of being Persistence Ignorant and use POCO in designing entity models. And so I guess I might spent some time preparing a talk about this topic.

After defining PI and POCO I started to talk about Entity Framework support for POCO & PI. And that POCO entities has no dependencies on Entity Framework. I explored a bit about what is happening behind the scene and generation of proxies to support lazy loading and change tracking. Then I moved to the Requirements for Using Persistence-Ignorant Objects.

Finally the demo time, I demonstrated 3 things:

Working without lazy loading and change tracking.
Support lazy loading with not change tracking. Showing how entities can be modified to support that
Support lazy loading and change tracking. Showing how entities can be modified to support that.

By coincidence, I made few mistakes through the demos that violating few requirements of PI support. It was a good chance to show the audiences that following the requirements to support our requirements is important.

I also debug through the code to show the audiences the proxy created behind the scene to support change tracking or lazy loading.

Code Generation Customization Using T4 templates

This was a short topic, I used the T4 POCO template provided with CTP 1 for demonstration. I explored few benefits behind code generation customization such as applying validation rules or business rules etc..

Honestly I never wrote T4 template before. And it isn’t easy specially with the no intellisense support in T4 editor that is shipped out of the box with VS.NET 2010 Beta 1. So I just walked through how to use an existing T4 template –I used the POCO T4 Template-

Code Only support in Entity Framework 4.0

Moving to another new feature provided through CTP 1. Code Only Support. The name describes itself. I introduced the idea to the audiences! but again because most of the audiences were intermediate and beginner and maybe students they didn’t recognize the value of this feature.

Beside it is still in CTP, many things will be introduced later to enrich this feature more and more.

A demo to show this feature was important. Showing the extension APIs for creating a database from the model, mapping keys, creating/adding entities and finally commit changes to the database.

Self Tracking Entities in Entity Framework 4.0

An exciting new feature shown in the CTP 1. A Template that generate self tracking entities. First I explained what is self tracking entities, and showed to the audiences that self tracking entities are just pure POCO entities.

Moved back into history the days of DataSets where it was used to transfer data over a service to client application that does modifications on it and then pass it back to the service to commit updates in data stores. Talked about how bad this can be over the wire and disadvantages of doing this.

Then talked about the concept of DTOs, then moved to Self Tracking entities, which simply eliminates the need for doing manual change tracking, and eliminates the need for DTOs by using simple lightweight entities.

Self Tracking entities can be generated using provided T4 template in CTP 1. But also it can be manually coded. It is matter productivity I guess.

I walked through the generated code by the template to prove that the entities is totally pure POCO with no dependencies on Entity Framework infrastructure.

My demo was based on the walkthrough of Self tracking entities posted on ADO.NET team blog. Except that it was totally different scenario. I made a simpler demo for time saving.

I didn’t made the full walkthrough described in the post also for time limitation.

Conclusion

Generally I enjoyed the session and it really helped me in understanding more about Entity Framework in general and EF4 in specific. It made me admire the work done by the Entity Framework team, comparing to the current version. But a general note, audiences always ask! Why we didn’t have all this at first release! Or at least the things related to better designer experience and productivity?! Questions that personally couldn’t answer. But I consider EF v1 was a good start! and EF4 was enhanced because of community participation, comments and feedback provided about EF v1.

Now it is time to start to learn about Entity Framework basics. Master them and be ready for the new version. Entity Framework won’t stop on EF4 it will evolve and will become more powerful in future. Just be ready for it, NOW!

To download the presentation and demos click here. Demos are based on Northwind database, the script of the database is provided in the downloadable archive.

NOTE: References are provided inside the presentation on slides’ notes.

Introducing Entity Framework Unit Testing with TypeMock Isolator

mosessaur — Sun, 06 Sep 2009 12:58:17 PDT

Introduction

One of the challenging things with current version of Entity Framework, its leakage of testability. Which means when you build an application or module (e.g. Repositories) that depends on entity framework, it will be very hard to unit test your code isolated from Entity Framework. This might lead to conduct Integration Testing which will require a connection and interaction with underlying data store (database).

You might think of using Mocking to mock or fake Entity Framework data store dependent calls. But sadly Moq and Rhino Mock mocking frameworks do not support this. And you’ll end up hitting the wall. Both frameworks are great useful and I personally use Moq for a while now and very happy with it. But no one can deny limitations when exist.

And personally I was able to overcome the limitation of the testability of Entity Framework while I was working in KiGG Entity Framework based models and repositories. But done that through unnecessary code refactoring and wrappers around none mockable classes such as sealed class EntityCollection<T>.

Finding a solution with TypeMock Isolator

In fact there is a solution, that will save you lots of workarounds and unnecessary code refactoring. You just need a full isolation framework. TypeMock Isolator provides this capability. It allows to mock sealed classes and classes that have private constructors, static methods, and much more.

TypeMock isolator makes it easy to simulate and break the dependencies of any object in your existing code. In that way, it doesn’t force you to think about how your design might need to change. –The Art of Unit Testing book page 132-

So, TypeMock isolator is a perfect mate for testing code that has dependencies on Entity Framework as how I am going to show now.

The Sample, snippet from KiGG

I am going to demonstrate how to use TypeMock isolator with Entity Framework through reflected model from KiGG project. Will use some code snippets from it and present single Repository class (class under test) and its Unit Testing class code. I’ll be using xUnit as my Unit Testing framework for simplicity.

Entity Framework Generated ObjectContext

After generating part of KiGG using Entity Framework wizard, an ObjectContext class is generated and it I called it KiGGEntityContainer. I added/enhanced the functionality of generated class by adding few methods such as InsertOnSubmit<TEntity>(TEntity entity) and DeleteOnSubmit<TEntity>(TEntity entity) methods.

public void InsertOnSubmit<TEntity>(TEntity entity)
    where TEntity : EntityObject
{
    string entitySetName = GetEntitySetName(typeof(TEntity));
    AddObject(entitySetName, entity);
}

public void DeleteOnSubmit<TEntity>(TEntity entity)
    where TEntity : EntityObject
{
    DeleteObject(entity);
}

In the above InsertOnSubmit method it calls a helper method GetEntitySetName. This method retrieve EntitySet name from the meta data.

Nothing to talk about more in this class, The test of this class is out of scope now as it will require access to EDM meta data. So for now it just directs calls to Entity Framework relevant methods AddObject & DeleteObject.

BaseRepository Class

A base generic class for all repositories. Very simple and contain basic functionality. There is nothing to test in this class as it has no logic at all. I’ll add its code for reference only and clarity.

public abstract class BaseRepository<TEntity>
    where TEntity : EntityObject
{
    private readonly KiggEntityContainer _context;

    protected BaseRepository(KiggEntityContainer context)
    {
        _context = context;
    }

    protected internal KiggEntityContainer DataContext
    {
        get
        {
            return _context;
        }
    }

    public virtual void Add(TEntity entity)
    {
        DataContext.InsertOnSubmit(entity);
    }

    public virtual void Remove(TEntity entity)
    {
        DataContext.DeleteOnSubmit(entity as TEntity);
    }
}

Model Class Under Test, Story class

Story is an entity model class. It has 3 navigations properties linking it with other 3 entities (User, Category and Tag).

Current version of Entity Framework doesn’t support transparent lazy loading. Only eager loading and explicit loading are supported. To over come this limitation, I marked the exiting navigation properties as internal. And made another properties that will handle the logic of loading related end if not already loaded just as the following:

public partial class Story
{
    public ICollection<Tag> Tags
    {
        get
        {
            if(!TagsInternal.IsLoaded)
            {
                TagsInternal.Load();
            }
            return TagsInternal;
        }
    }

    public Category Category
    {
        get
        {
            if(!CategoryInternalReference.IsLoaded)
            {
                CategoryInternalReference.Load();
            }
            return CategoryInternalReference.Value;
        }
    }
}

The above 2 properties will need to be tested as they contain logic. What I need to test here is when IsLoaded property of EntityCollection<Tag> (TagsInternal) Or EntityReference<Category> (Category) returns false, Load() method must be called. And if it return false, Load() method mustn’t be called. Here is the first test method –code is commented for clarification-

[Fact]
public void Tags_Should_Call_Load_When_IsLoaded_Is_False()
{
    // Arrange
    var story = new Story(); //Live Object
    //Fake the return of IsLoaded property of EntityCollection<Tag>
    Isolate.WhenCalled(() => story.TagsInternal.IsLoaded)
           .WillReturn(false);
    //Fake the call of Load method by ignoring the call.
    //Not doing so will throw an exception because
    //Load is supposed to load data from data store.
    Isolate.WhenCalled(() => story.TagsInternal.Load())
           .IgnoreCall();
    #pragma warning disable 168
    //Act: Issue call to Tags property
    ICollection<Tag> tags = story.Tags;
    #pragma warning restore 168
    //Assert: Verify that Load method has been called.
    Isolate.Verify
           .WasCalledWithAnyArguments(()=>story.TagsInternal.Load());
}

What exactly TypeMock Isolator provided me here?

It was impossible with any other Mocking framework to fake method calls on live object (real object not faked) or one of its properties. In this case the live object the story instance.
Faking EntityCollection<T> or any of its properties or methods also impossible with other Mocking frameworks, because the class is sealed! TypeMock totally isolate me from Entity Framework by giving the ability to fake Entity Framework types and dependent method calls such as calling IsLoaded property of EntityCollection<T> and Load() method.

As you see, TypeMock isolates my entity class test from Entity Framework although it depends on it. The rest of this StoryFixture test class is included in the attached sample.

The Class Under Test, CategoryRepository

In this class I have 5 methods which I need to test. 3 or them concerns with LINQ to Entities queries and the other 2 are for Add and Remove, both of these 2 methods contains logic that I must be tested. For sample I’ll introduce the Add method:

public override void Add(Category category)
{
    if (DataContext.Categories.Any(c => c.Name == categoryName))
    {
        throw new ArgumentException("Some Error Message...", "category");
    }

    category.UniqueName = UniqueNameGenerator.GenerateFrom(DataContext.Categories, category.Name);

    base.Add(category);
}

The Add method checks if the name exists in the data source or not. If exists an exception should be thrown. If not a unique name to be generated for the category and then to be added to current ObjectContext for later saving.

Issues with testing such method is that it depends on Entity Framework. And current version of Entity Framework will require a database hit to evaluate this query “DataContext.Categories.Any(c => c.Name == categoryName)”!!

Again TypeMock is a saver here. TypeMock is able to fake any ObjectContext instance. Which is not supported by other mocking engines. Faking ObjectContext instance and having the ability to fake all of its method calls and properties is really great thing. I missed that with Moq!

First test for this method is to check if an exception is thrown when a new category is added and there is existing one with the same name –Code commented for clarification-:

[Fact]
public void Add_Existing_Category_Should_Throw_ArgumentException()
{
    //Fake KiggEntityContainer -ObjectContext-
    var context = Isolate.Fake
                      	.Instance<KiggEntityContainer>(Members.ReturnRecursiveFakes);

	//Fake call to dependecy static method on static class UniqueNameGenerator
    Isolate.Fake
           .StaticMethods<UniqueNameGenerator>(Members.ReturnRecursiveFakes);

    var repo = new CategoryRepository(context);
	//Create In memory list of categories
    var inMemoryCategories = new List<Category>
               							{
                   						new Category{Name = "Dummy1"}, 
                   						new Category{Name = "Dummy2"}
               							};
    
    //Fetch existing category name
    string name = inMemoryCategories[0].Name;

	//Fake the return of ObjectQuery<T> "context.Categories"
	//Instade of using physical datastore I'm using In Memory Store
	//LINQ to Entites will be simulated with LINQ to Objects
    Isolate.WhenCalled(() => context.Categories)
           .WillReturnCollectionValuesOf(inMemoryCategories.AsQueryable());

	//Assert 
    Assert.Throws(typeof(ArgumentException), 
									() => repo.Add(new Category { Name = name }));
}

Line 5 using fluent AAA (Arrange-Act-Assert) TypeMock APIs to fake an instance -Mock- of KiggEntityContainer object context class. If you tried to do this with Moq for example you’ll desperately receive and exception that EDM meta data couldn’t be loaded. Note here that I also don’t care about the constructor parameters. I like this total isolation.

Line 9 I am faking –subbing- a call to as static method on some static class. I just need to fake its call, and this test doesn't really care about its returned value

Line 14 I am creating an in memory collection of categories. which will be used in replacement for underlying data store as we will see.

Line 26 the most important line. In this line the powerful of TypeMock shown. Here I’m able to fake the return value of ObjectQuery<Category> “context.Categories”. So simply they like says when calling context.Categories return the in memory collection of categories “inMemoryCategories”. There is a trick on this line of code to make it work; I have to call AsQueryable() of the replacement collection. If I didn’t I’ll receive and exception.

Finally Line 30, Asserting that an exception is thrown when call Add method of CategoryRepository instance when passing a new Category with a name that match an existing category in the underlying data source.

Another method in CategoryRepository which is FindByUniqueName is used to retrieve a category by its unique name here is the method:

public Category FindByUniqueName(string uniqueName)
{
	return DataContext.Categories.FirstOrDefault(c=>c.UniqueName == uniqueName);
}

Very simple method with no logic! So what exactly I need to test here? Zooming into code, you’ll notice that I want to a category when its unique name matches a specific input. I want to test this LINQ expression that it yields the correct results.

Here is the test method

[Fact]
public void FindById_Should_Return_Correct_Category()
{
    //_context is a fake ObjectContext instance
    var repository = new CategoryRepository(_context);
    
    //In memory collection store of categories
    List<Category> inMemoryCategories = new List<Category>
               				{
                   			new Category{Id=Guid.NewGuid(),Name = "Dummy1"}, 
                   			new Category{Id=Guid.NewGuid(),Name = "Dummy2"}
               				};
    
    Guid id = inMemoryCategories[0].Id;

    //Fake ObjectQuery<Category>
    //Must call AsQueryable() extension in order for this to work
    Isolate.WhenCalled(() => _context.Categories)
           .WillReturnCollectionValuesOf(inMemoryCategories.AsQueryable());
    
    //Act
    Category found = repository.FindById(id);

    //Assert
    Assert.Equal(id, found.Id);
}

Again I am replacing (faking) the return of ObjectQuery<Category> with in memory list of categories. This way when _context.Categories is called an in memory IQueryable<Category> will be returned. The LINQ will be evaluated as LINQ to Object an not as LINQ to Entities. Because LINQ to Entities will require a database hit which I want to avoid.

This way TypeMock Isolator provided an isolation from Entity Framework, although my component is totally dependent on Entity Framework. This is impossible with other mocking framework which shows the strength of TypeMock in this point.

Code for this sample downloadable from here. Note that I didn’t include TypeMock assemblies which you should download from here

Conclusion

There is a white paper published by TypeMock with comparing different mocking framework to TypeMock itself. This comparison white paper is downloadable from here. Also there is an open source project to compare between mocking frameworks which you can check it out here.

I’ve been working with different mocking framework for a while now. Moq is my favourite free open source one. I also worked a little with Rhino Mock, a great framework however at the time I was working Moq, I didn’t feel comfortable with record & replay mode of Rhino Mock. Beside Moq was very simple and very easy to learn. Rhino Mock is going to rock in its upcoming version 4.0 you can read about its plans here.

TypeMock is the most powerful mocking framework I ever seen so far. as I mentioned earlier TypeMock isolator makes it easy to simulate and break the dependencies of any object in your existing code. In that way, it doesn’t force you to think about how your design might need to change. –The Art of Unit Testing book page 132-.

TypeMock can isolate almost everything, they even have specific release for unit testing with SharePoint which so far no tool compete on this with it.

TypeMock is commercial, However, they provide free license for open source projects. And for MVPs, they are eligible for a free version TypeMock Isolator Enterprise Edition! MVPs can check it out here.

Download the Sample

Multiple database support with Entity Framework

mosessaur — Tue, 18 Aug 2009 12:46:42 PDT

Introduction

One of the features introduced in Entity Framework is being database independent. Which mean each database provider can support Entity Framework by implementing its provider.

This feature allows you build applications independent from the underplaying database provider. In this post I’m going to show how to build an application that support multiple databases using same conceptual model made by Entity Framework.

Entity Framework providers

Entity Framework is database independent. Each database provider could have its own Entity Framework provider. Currently there are several database provider who support the current version of Entity Framework that is released with .Net 3.5 SP1.

A list of Entity Framework providers can be found here.

Entity Framework multiple database support sample

In this post, I am going to demonstrate a sample application (based on northwind database) that is going to support both SQL Server database engine and MySQL database engine.

MySQL Entity Framework provider (connector/net)

MySQL Entity Framework provider I am going to use is connector/net ADO.NET provider for MySQL. It is a free provider and open source built by MySQL .Net data provider team. The version I am using is a modified version (by me) of connector/net 6.0.3. At the time of writing this post current release is 6.0.4.

How to prepare your Entity Data Model for multi-database support?

In order to keep your conceptual model (CSDL) static and ready to be used with different databases you should make sure that your database schema is the same across all database engine you plan to support.

For example, Northwind database schema in SQL Server is the same as Northwind database in MySQL. There are differences in data types, for example uniqueidentifier doesn’t exists in current version of MySQL, however there is a replacement which could be varbinary(16). Also data types might differ in names but there representation in .Net is the same, for example there is bit in SQL server and boolean -tinyint- in MySQL can be mapped to Boolean -bool- in .Net. Schema includes views and stored procedures/user defined functions (names, parameters and return results)

As conclusion, you have to maintain your database schema across any engine you wish to use to keep your CSDL untouchable. However change in your storage schema in EDM (SSDL) is mandatory as we are going to see later.

Steps support multiple database providers using Entity Framework

Modifying the SSDL

First step would be preparing your database on the provider you wish to work with. In my case it is MySQL. Script of northwind database on MySQL is attached with this post.

Next step is to modify your SSDL! If you are using VS.Net 2008 SP1 Entity Framework designer then your probably got a EDMX file for the generated EDM. the EDMX combines all CSDL,SSDL and MSL in it. You need just to have another SSDL file for your new database under MySQL.

To proceed with this, just create another file with and call it for example Northwind.MySQL.ssdl. Set its Copy to Output Directory option to Copy Always. Then add the following at the top of the new document (XML root):
<?xml version="1.0" encoding="utf-8"?>
Then follow the following steps to extract (copy) SSDL from the generated EDMX

Right click on your EDMX file “Northwind.edmx” and select “Open With…” from the context menu.
From “Open With” dialog select XML Editor (make sure you already saved your EDMX). An XML view of your EDMX will appear.
Find an XML comment  where you will find underneath it a StorageModels element.
Copy the content of Schema element under StorageModels element (without StorageModels element)
Past what you just copied into Northwind.MySQL.ssdl

After you got your copy of SSDL file you’ll need to modify it. Lets walkthrough where the modification should take place.

The Schema element contain several attributes. 2 of them should be changes to a new values. Provider and ProviderManifestToken attributes.

Provider attribute specify the underlying .Net data provider name that should be used for this storage schema (SSDL). So change its value to “MySql.Data.MySqlClient”.
ProviderManifestToken used to load the provider manifest for offline scenarios.There is no specific schema for the token; it is up to the provider to choose the minimum information needed to identify a manifest without having to open a connection to storage. You’ll notice in most cases it shows a version of the underlying database engine. So in MySQL case it should be “MySQL5”.

The final output of Schema element should look like this:

<Schema Namespace="NorthwindModel.Store" Alias="Self" 
   Provider="MySql.Data.MySqlClient" 
   ProviderManifestToken="MySQL5" 
   xmlns:store="http://schemas.microsoft.com/ado/2007/12/edm/EntityStoreSchemaGenerator" 
   xmlns="http://schemas.microsoft.com/ado/2006/04/edm/ssdl">...
</Schema>

The next changes are related to the storage schema (schema name and data types).

On each EntitySet element there is an attribute called schema. In case of SQL Server this attribute is set to the related table schema. In MySQL you just need to set this attribute to the name your database.

<EntitySet Name="Categories" .... Schema="northwind" />

Note: in the above code snippet part of code is omitted for clarification.

Now under each EntityType element there are several Property elements. Each Property element maps to a database table column with the same name. And of course should be of the same data type. That is why there is a Type attribute for each Property element.

Sometimes (depending on provider mapped data types) you’ll need to change this Type attribute for several Property elements. For example MySQL provider doesn’t recognize the data type ntext which supported by SQL Server. However another data type could be used such as MEDIUMTEXT or LONGTEXT.

You should correct such things in your Schema EntityTypes Properties. Happy that Nothwind isn’t complicated at all and most of the data types used with it are common between both engines. I just had to change few types.

Now we are done with SSDL modification, and time to move to Connection String.

Modifying Connection String

I left this to the end. Changing connection string would the most easy task. I highly recommend to read about Connection Strings in Entity Framework.

The connection string generated to you would be something like this:

<connectionStrings>
 <add name="Northwind" 
  connectionString="metadata=res://*/NorthwindModel.csdl|res://*/NorthwindModel.ssdl|res://*/NorthwindModel.msl;provider=System.Data.SqlClient;provider connection string=&quot;Data Source=.\SQLExpress;Initial Catalog=Northwind;Integrated Security=True;&quot;" 
  providerName="System.Data.EntityClient" />
  </connectionStrings>

A change to connection string is mandatory to specify different ssdl file, provider and provider connection string. All these information is provided above as a value to connectionString attribute of add element.

A modified Connection string would be like this:

<add name="NorthwindEntitiesMySQL"
 connectionString="metadata=Northwind.MySql.ssdl|res://*/NorthwindModel.csdl|res://*/NorthwindModel.msl;provider=MySql.Data.MySqlClient;provider connection string=&quot;server=localhost;user id=root;password=Pa$$w0rd;persist security info=True;database=northwind&quot;" 
 providerName="System.Data.EntityClient" />

Note that metadata value is changed. It now points to Nothwind.MySQL.ssdl file that is not part of assembly resource, but a file on the same folder of the executing assembly. Also provider value change to MySql.Data.MySqlClient and provider connection string is changed to “server=localhost;user id=root;password=Pa$$w0rd;persist security info=True;database=northwind”.

Note that you also can choose to make your Northwind.MySQL.ssdl as part of assembly resources by changing the Build action of the file to be Embedded Resource and Copy to Output Directory option to Do not copy. In this case your metadata value will be “metadata=res://*/Northwind.MySql.ssdl|res://*/NorthwindModel.csdl|res://*/NorthwindModel.msl”.

Now have a look at the attached sample project. Notice that there is no change in code that access the entity framework, just changing the connection string to use another one.

Conclusion

Being database independent is a great feature that comes out of the box with Entity Framework. Being able to switch to another database engine without touching your code is one big feature I admire myself. Just changes in SSDL and connection string and you are done to go live on another database with your application.

We already applied this practically with latest release of KiGG. Now KiGG supports repositories and models that are implemented with current version of Entity Framework. KiGG -with appreciation to Entity Framework- supports both SQL Server and MySQL. No code change –check it yourself-

Feel free to download KiGG or the attached sample to explore this cool feature.

Introducing Entity Framework v1 in DotNetWork User Group in Cairo Egypt

mosessaur — Sat, 18 Jul 2009 02:09:23 PDT

Bishoy Ghaly & me made an introductory presentation about Entity Framework for the first time in DotNetWork User Group in Cairo, Egypt –Saturday 18th July-

After a survey we made in June we discovered that an introductory session to Entity Framework is a must. So we prepared this 3 hours session -level 100- to introduce Entity Framework to the audiences.

Our agenda:

History of ADO.Net
Object Relational Mapping {ORM}
What is Entity Framework?
Entity Framework Architecture
Entity Data Model {EDM}
Entity Client & Object Services
LINQ to Entities & Entity SQL {eSQL}
Load Related Objects
Inheritance in Entity Framework
Entity Framework providers and multiple database support
Entity Framework Limitations (if time permits)
External Tools (if time permits)

The presentation had around 10 Demos. All of them are meant for introducing Entity Framework in basic level.

We have a plan to blog about few topics mentioned in the above agenda. Also these posts will be very basic as it will be related to the presentation.

Session presentation (Power Point), presenters’ script and demos are available for download (Click here).

Silverlight 3 is out with SDK and Tools with useful links

mosessaur — Fri, 10 Jul 2009 18:01:09 PDT

Silverlight 3 is out, Scott Guthrie Announced that on his blog. As I was started to upgrade my client, I thought it would be useful to search for the SDK and Silverlight 3 VS.NET tools too. Thought to share the following quick links for Silverlight 3

Silverlight technical resource
Silverlight 3 for Developers
Silverlight Tools for Visual Studio.Net 2008 SP1
Microsoft® Silverlight™ 3 SDK (Silverlight 3 SDK is installed by Microsoft Silverlight Tools automatically)
Microsoft Silverlight 3 Offline Documentation

KiGG support for Entity Framework and MySQL

mosessaur — Tue, 07 Jul 2009 12:39:37 PDT

Introduction

KiGG is a Web 2.0 style social news web application developed in Microsoft supported technologies. It is an open source project hosted on CodePlex. It is live and running as DotNetShoutout.com.

KiGG and Entity Framework

On May 2009, I’ve completed the implementation of Entity Framework support on KiGG. KiGG design was very flexible to plug another repository implementation other than LINQ to SQL. So basically now KiGG comes with 2 repository flavours, LINQ to SQL and Entity Framework.

Read about how to configure your KiGG application to use Entity Framework.

KiGG and MySQL

After Entity Framework implementation is completed, I wanted to gain benefit of it. I wanted to support multiple databases using Entity Framework without changing the code!

Entity Framework Entity Data Model (EDM) separate storage model (SSDL) from conceptual model (CSDL). The Conceptual model mustn’t be touched under any circumstances. Only storage model (SSDL) is subject to change because it is couple with underlying data provider and database engine.

My first candidate database engine was MySQL. And successfully added support to MySQL using MySQL Connector/net.Net Data Provider for MySQL (free) and Devart .Net Data Provider for MySQL (commercial)

Read about how to configure KiGG to use MySQL database.

IMPORTANT NOTE:
I modified MySQL Connector/net code to fix few issues related to LINQ to Entities, Entity SQL and Guid support. KiGG do not support the provider released by MySQL Connector/net, instead use the modified version.

Soon I will blog about how to target different database engines using Entity Framework in single application so stay tuned.

KiGG Entity Framework and MySQL Support How-To:

I wrote couple of articles -detailed- on project wiki as documentation. Feel free to reference those articles in order to configure your KiGG application to use Entity Framework and MySQL:

Microsoft ADO.NET Entity Framework Feature CTP 1 Post Beta 1

mosessaur — Tue, 30 Jun 2009 09:38:26 PDT

Microsoft ADO.Net team released (this month June 2009) a set of features that build on top of Entity Framework 4.0 Beta 1
The features included in this CTP are :

Templates for Self-Tracking Entities (N-Tier support)
Templates for POCO (Plain Old CLR Objects) Entities
Code-Only Programming Model that allows you to write Entity Data Model based applications without requiring external artifacts

CTP can be downloaded here

Enjoy it.

Entity Framework minimum permission considerations

mosessaur — Thu, 21 May 2009 11:50:04 PDT

Introduction

While working with Entity Framework v1 during KiGG implementation of Entity Framework repositories, I decided to test KiGG for partial trust environment. Particularly Medium Trust support. Will not go through whether KiGG currently support medium trust or not in it current or upcoming version, but I will go through one of the reasons why KiGG currently might not support medium trust. It is because MY implementation of Entity Framework. Note that I am saying MY, because Entity Framework application can run on medium trust.

Running Entity Framework applications with minimum permissions

The following is a snippet from MSDN documentation Security Considerations (Entity Framework):

The following code access permissions are the minimum permissions your Entity Framework application needs:

FileIOPermission: Write to open the specified metadata files or PathDiscovery to search a directory for metadata files.

ReflectionPermission: RestrictedMemberAccess to support LINQ to Entities queries.

DistributedTransactionPermission: Unrestricted to enlist in a System.Transactions Transaction.

SecurityPermission: SerializationFormatter to serialize exceptions by using the ISerializable interface.

Permission to open a database connection and execute commands against the database, such as SqlClientPermission for a SQL Server database.

What I am going to focus on is the 2nd point (in bold). Entity Framework request ReflectionPermission with RestrictedMemberAccess to support LINQ to Entities queries. You need to know what is RestrictedMemberAccess.

RestrictedMemberAccess allows access to non-public members, with the restriction that the grant set of the non-public members must be equal to, or a subset of, the grant set of the code that accesses the non-public members.

In Medium Trust environment, ReflectionPermission is granted but with RestrictedMemberAccess. So what does that means?!

It simply means if you have an Entity Class with a non-public property and you are using this property in any of your LINQ to Entities queries, the following exception will be your punishment.

SecurityException: Request for the permission of type 'System.Security.Permissions.ReflectionPermission failed

How to enable your Entity Framework implementation to run on medium trust environment?

I think you already guessed the answer. Just make your Entity Classes’ properties that will participate in LINQ to Entities queries public. I would recommend also to make the entities itself public as well.

Conclusion

Don’t think of this as a limitation of Entity Framework, myself I don’t think so. I also expect this behaviour in LINQ to SQL too as. I guess I should correct this in KiGG by marking used properties in queries as public.

I made a sample to demonstrate the exception and its cause. Feel free to download the sample and explore it.

Entity Framework 4 Persistence-Ignorance First Look

mosessaur — Wed, 20 May 2009 14:36:20 PDT

Introduction:

From the moment I put my hands on Visual Studio.Net 2010 Beta 1 and I’m targeting EF4 –Entity Framework 4- as I was very excited to checkout the new cool feature of it.

Here I am going to highlight my first look at Persistence-Ignorance support in EF4.

EF4 Support for POCO classes:

Well, what I can say?! it as simple as writing something like this:

public class Category
{
    public int CategoryID { get; set; }
    public string CategoryName { get; set; }
    public string Description { get; set; }
    public ICollection<Product> Products { get; private set; }
}

The above code is your POCO class. The class name exactly matches the Entity Type in CSDL and so all the properties.

So what about ObjectContext?! I implemented my own simple one for demonstration:

public class NorthwindObjectContext : ObjectContext
{
    public NorthwindObjectContext(string connectionString)
        : base(connectionString, "NorthwindContext")
    {
    }

    private IObjectSet<Category> _categorySet;

    public IObjectSet<Category> CategorySet 
    {
        get 
        {
            if (_categorySet == null)
            {
                _categorySet = CreateObjectSet<Category>();
            }
            return _categorySet;
        }
    }
}

On a simple console application I made the following.

public static void Main(string[] args)
{
 using (var context = new NorthwindObjectContext("name=NorthwindContext"))
 {
	try
	{
		var category = context.CategorySet.First();
		Console.WriteLine(category.CategoryName);
	}
	catch (Exception ex)
	{
		Console.Write(ex.ToString());
	}
 }
}

And to checkout also that it supports Compiled Queries I made one

private readonly static Func<NorthwindObjectContext, int, Category> FindCategoryById = 
            CompiledQuery.Compile<NorthwindObjectContext, int, Category>(
            (db,id) => db.CategorySet.SingleOrDefault(c=>c.CategoryID==id));

And the run it

var category = FindCategoryById.Invoke(context,2);
Console.WriteLine(category.CategoryName);

And that was great for a first touch. It became more easier.

About Change Tracking & Deferred Loading:

One important thing I must clarify about my POCO class above (the Category class). This class doesn’t support change tracking or transparent deferred loading (lazy loading). So for example if you tried to get Products property of Category class, it will return null.

And if you modified the category instance and just call context.SaveChanges(true); this will have no effect because the category instance is already not tracked for any change.

Of course these is a reason of that. The reason is stated on the requirement of Persistence-Ignorant Objects on MSDN to enable POCO classes to support self-change tracking as well as deferred loading. Here is what MSDN states:

Class Definition Requirements

To be able to generate the proxy objects that are required by Object Services to track changes and to support deferred loading of related objects, custom data classes must meet the following requirements. (read more about class POCO class definition requirements in EF4)

So for this sample I will not implement these requirements (keep tuned for next posts) But I will show how to explicitly load related objects and submit changes.

Explicit loading of related objects using newly introduced method LoadProperty:

private static void FetchSample()
{
 	using (var context = new NorthwindObjectContext("name=NorthwindContext"))
 	{
		try
		{
			//By default it is false
			context.ContextOptions.DeferredLoadingEnabled = true;
        
			//using compiled queries
			var category = FindCategoryById.Invoke(context, 2);

			//Explicit Loading of Products
			context.LoadProperty<Category>(category, c => c.Products);
			Console.WriteLine("{0} has {1} products", 
													category.CategoryName, 
													category.Products.Count);

			category = context.CategorySet.First();
			Console.WriteLine(category.CategoryName);
		}
		catch (Exception ex)
		{
			Console.Write(ex.ToString());
		}
	}
}

And for submitting changes:

private static void UpdateSample()
{
	using (var context = new NorthwindObjectContext("name=NorthwindContext"))
	{
		try
		{
			context.ContextOptions.ProxyCreationEnabled = true;
			var category = FindCategoryById.Invoke(context, 1); //context.CategorySet.First();
            
			Console.WriteLine("{0}:{1}",category.CategoryName, category.Description);
			category.Description = category.Description + "[Updated]";
            
			//No generated proxy classes => No tracking
			//Call DetectChanges(); Explicitly
			//Ref: http://msdn.microsoft.com/en-us/library/dd456848(VS.100).aspx
			context.DetectChanges();    
			context.SaveChanges();
			Console.WriteLine("{0}:{1}", category.CategoryName, category.Description);
		}
		catch (Exception ex)
		{
			Console.Write(ex.ToString());
		}
	}
}

At line 16 I am calling DetectChanges method. There is an alternate way which is to call SaveChanges(SaveOptions) and supply a value of DetectChangesBeforeSave. In this case DetectChanges is automatically called before changes are persisted to the data source.

Conclusion:

EF4 is really far away of EF v1. Totally brand new product. It will beat the popularity LINQ to SQL had earlier especially after all new added features to it.

I will blog soon about deferred loading and change tracking with EF4 after applying POCO class definition requirements.

Download the sample (requires VS.Net 2010 Beta 1)

NOTE: The sample is using Northwind database which is not attached. You can download it from Microsoft web site

MSDN References:

ADO.NET Team Blog

Introducing DataLoadOptions for Entity Framework ObjectContext

mosessaur — Sat, 16 May 2009 09:05:10 PDT

On my previous post “What about DataLoadOptions for Entity Framework ObjectContext?” I was suggesting another way to define eager loading for Entity Framework. In this post I will introduce my DataLoadOptions for Entity Framework ObjectContext.

The beginning:

Actually Eager and Lazy loading on Entity Framework is not that much fun like in Linq to Sql. However this is going to be improved in EF4.

Here I will focus on eager loading and my slight improvement to define eager loading in Entity Framework. When I start to think about, I wanted something simple and pretty close to the way Linq to Sql work. In Linq to Sql it is the DataLoadOptions that helps you define eager loading before start using Linq to Sql DataContext.

So I started to explore the DataLoadOptions code using reflector, to better understand how it works and how it helps Linq to Sql define eager loading.

The Idea:

The idea was very simple here it is:

First I need to register the entity members that I wish to pre load when retrieving root entity. This should be achieved with this syntax dataLoadOptions.LoadWith<Product>(p=>p.Category). My DataLoadOptions should store that I want to pre load product’s category whenever I attempt to load a product record.
I should provide my ObjectContext with a DataLoadOptions instance:
context.LoadOptions = dataLoadOptions;
Before trying to retrieve any EntitySet (context.ProductSet) I should start prepare the query to include all registered preloaded members using ObjectContext.Include method.

public partial class NorthwindObjectContext: ObjectContext
{
	public ObjectQuery<Product> ProductSet
  {
  	get
		{
			if (_productSet==null)
			{
				_productSet  = ApplyDataLoadOptions<Product>("ProductSet");
			}
			return _productSet;
		}
	}

	private ObjectQuery<TEntity> ApplyDataLoadOptions<TEntity>(string queryString)
	{
		var query = CreateQuery<TEntity>(queryString);

		if (LoadOptions != null)
		{
			var members = LoadOptions.GetPreloadedMembers<TEntity>();

			foreach (var member in members)
			{
				query = query.Include(member.Name);
			}
		}
		return query;
	}
}

You should know that this idea is close the one in Linq to Sql but it is not exactly the same.

Implementation:

I had attached a sample code to this post that include the implementation of DataLoadOptions class, to save space I will let that to you to explore.

Part of the implementation is to have ApplyDataLoadOptions method (or call it whatever you want) as in line 15 above. This method is using GerPreloadedMembers<TEntity> method of DataLoadOptions instance to get all registered properties for eager loading. Then it loops through those members and call Include method passing member/property name, finally found a good usage of having Include method accepting string.

Here is a sample usage code:

using(var context = new NorthwindObjectContext())
{
    var loadOptions = new DataLoadOptions();
    loadOptions.LoadWith<Product>(p => p.Category);
    loadOptions.LoadWith<Product>(p => p.Supplier);
    
    context.LoadOptions = loadOptions;
    
    var queryString = context.ProductSet.ToTraceString();
		var products = context.ProductSet;
		foreach(var product in products)
		{
			Console.WriteLine(product.Category.Name);
		}
    Console.WriteLine(queryString);
}

Hints:

The following is not allowed in Linq to Sql:

loadOptions.LoadWith<Product>(p=>p.Category);  
loadOptions.LoadWith<Category>(c=>c.Products);

This should throw an exception. In Entity Framework this is not the case it will work. Not because this implementation is much better than the on in Linq to Sql, but because it is different and work differently than Linq to Sql.

Conclusion:

EF4 is promising, and I highly recommend that you keep tuned about what ADO.NET on Entity Framework doing. So far I didn’t read about what they are going to provide for Eager Loading, but I expect that soon.

I have plugged this implementation of DataLoadOptions into KiGG EF implementation. I wanted to keep both Linq to Sql And Entity Framework implementations on KiGG as close as possible. I’ve tested it and I guess it is stable enough to be used in production.

Sample Download

You comments and suggestions are appreciated.

What about DataLoadOptions for Entity Framework ObjectContext?

mosessaur — Thu, 23 Apr 2009 18:50:48 PDT

I think the proper way to start this post is to ask How do you do eager loading with Entity Framework? And the basic native simple answer is by using ObjectQuery<T>.Include(string) method. No matter what you tried to do, you’ll end up using this way.

So there was ideas about how enhance the eager loading in our Entity Framework base applications. You can read about some of these ideas:

As I said, no matter what you tried, you’ll end up using ObjectQuery<T>.Include(string).

My Proposal:

I am here now to propose my idea. And I am just proposing. What about DataLoadOptions for Entity Framework ObjectContext?! Do You know DataLoadOptions class in Linq to Sql?! Yes, I want to steal the idea and make it fit for Entity Framework. I want to implement a tiny clone of DataLoadOptions for Entity Framework. This would give you an option similar to this:

var context = new NorthwindObjectContext;
var loadOptions = new DataLoadOptions()
DataLoadOptions.LoadWith<Product>(p=>p.Category)
DataLoadOptions.LoadWith<Product>(p=>p.Supplier)

context.LoadOptions = loadOptions;

var products = context.ProductsSet;

Of course this is not going to work by itself. The above is a usage sample, however the implementation of such feature will require some coding, and guess what, I’ll end up using ObjectQuery<T>.Include(string).

Where did I reach?

I am almost done with this idea! The DataLoadOptions class for EF is completed with tests. It worth to mention that this class is not 100% clone of LINQ to SQL DataLoadOptions one! There is a big difference. And I can say for some reason in EF you will not fall in mistakes like cyclic issues (read about it on DataLoadOptions remarks section) for example in LINQ to SQL you cannot do this:

loadOptions.LoadWith<Product>(p=>p.Category);
loadOptions.LoadWith<Category>(c=>c.Products);

But in EF it would be safe because you can control implicitly.

Conclusion:

I hope soon I’ll be able to present a demo code. But for now I can say it will be as reusable code that you’ll have to customize to attache to your EF implementation. I am currently integrating it into KiGG as part of EF flavour of repository on KiGG. At the moment I am writing this post I didn’t comment it to KiGG source control. So keep tuned.

Enterprise Library 4.1 Hands-on-Labs

mosessaur — Thu, 02 Apr 2009 13:35:34 PDT

Last month (March 2009) HOLs for Enterprise Library 4.1 released. Earlier this year there were HOLs released for Validation Application Block 4.1, now a full HOLs is released for the entire Enterprise Library.

Hands-on Labs walk you through the key usage scenarios of the application blocks in in various application contexts. You can practice the labs from start to finish or you can use the starter solutions provided to complete only the labs you want to, in the order you prefer.

Domain Driven Design & Test Driven Development\Design using Entity Framework, Part 2.A Unit Testing Entities With Moq 3

mosessaur — Tue, 24 Mar 2009 13:10:36 PDT

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:

The above image shows class diagram of my northwind domain model. It is a set of interfaces where I define data contracts of each entity. It is very simple, but there is one thing I want to highlight in this model. It is the IEntityCollection generic interface. Actually this is an empty interface that is considered a combination of ICollection<T>, IEnumerable<T>, IEnumerable and IListSource. This interface defines a collection of related entities such as the case ICategory that should contains a collection of IProduct.

So ICategory should contain an IEntityCollection of products IEntityCollection<IProduct>. Same thing for ISupplier. And for IProduct it should contain a navigation property for both ISupplier and ICategory.

Issue with EF generated entities:

EF generated entities cannot be tested without physical connection to data source. For example generated entities cannot be mocked because it will require a physical data source. But interfaces can be mocked. And because we have entities that implements those interfaces, then we need to test these entities.

Regardless of mocking, you'll also face troubles when you work with real entities specially when you try to access navigation properties or collections. Especially if the collection are lazy loading ones. Then you will need to call Load which will require to hit the data store to retrieve related collection of data.

What Exactly I need to test in entities?

Basically I need to test navigation properties both scalar and collection ones. Navigation properties in EF depends on EntityReference<T> and EntityCollection<T> classes. Both are sealed classes, also these generated properties such as EntityCollection of products will require to hit data store. So I cannot mocke instance of those classes.

For example I need to test Category.Products that it loads data if not already loaded. This is what I want to test and without connecting to data store. Same thing for Product.Category which will require the EntityReference<Category> to be loaded in order to Category property of Product class to return a result.

So I will need to mock EntityReference<T> properties and EntityCollection<T> properties. And as I mentioned above they cannot be mocked because they are sealed. So my solution was to build a wrapper for both classes in order to be able to mock them.

public class EntityReferenceWrapper<TEntity> 
	where TEntity : class, IEntityWithRelationships, IEntity
{
    EntityReference<TEntity> _entityReference;
    public EntityReferenceWrapper(EntityReference<TEntity> entityReference)
    {
        _entityReference = entityReference;
    }
    
    [SoapIgnore]
    [XmlIgnore]
    public virtual TEntity Value 
    { 
        get { return _entityReference.Value; } 
        set { _entityReference.Value = value; } 
    }

    public void Attach(TEntity entity)
    {
        _entityReference.Attach(entity);
    }

    public ObjectQuery<TEntity> CreateSourceQuery()
    {
        return _entityReference.CreateSourceQuery();
    }

    public virtual void Load()
    {
        _entityReference.Load();
    }

    public virtual bool IsLoaded
    {
        get
        {
            return _entityReference.IsLoaded;
        }
    }
}

public class EntityCollectionWrapper<TInterface, TEntity> : IEntityCollection<TInterface>
    where TInterface : class, IEntity
    where TEntity : class, IEntityWithRelationships, TInterface
{
    private readonly EntityCollection<TEntity> _entityCollection;
    public EntityCollectionWrapper(EntityCollection<TEntity> entityCollection)
    {
        _entityCollection = entityCollection;
    }

    public int Count { get { return _entityCollection.Count; } }
    public bool IsReadOnly { get { return _entityCollection.IsReadOnly;} }
    public virtual bool IsLoaded
    {
        get { return _entityCollection.IsLoaded; }
    }
    public virtual void Load()
    {
        _entityCollection.Load();
    }
    public virtual IQueryable<TEntity> CreateSourceQuery()
    {
        return _entityCollection.CreateSourceQuery();
    }
    public bool Contains(TInterface entity)
    {
        return _entityCollection.Contains(entity as TEntity);
    }
    public void Add(TInterface entity)
    {
        _entityCollection.Add(entity as TEntity);
    }
    public bool Remove(TInterface entity)
    {
        return _entityCollection.Remove(entity as TEntity);
    }
    public void Clear()
    {
        _entityCollection.Clear();
    }
    public void CopyTo(TInterface[] array, int arrayIndex)
    {
        TEntity[] entitiesArray = null;
        _entityCollection.CopyTo(entitiesArray, arrayIndex);
        array = entitiesArray.Cast<TInterface>().ToArray();
    }
    public IEnumerator<TInterface> GetEnumerator()
    {
        return _entityCollection.Cast<TInterface>().GetEnumerator();
    }
	//IListSource & IEnumerator implementation were omitted for code clearance
}

Unit Tests for Entities:

Each of ICategory and ISupplier contains IEntityCollection<Product> property called Products. While IProduct has 2 navigation properties for ICategory (Category property) and ISupplier (Supplier property).

For ICategory or ISupplier implementations which would be generated and modified entities Category and Supplier classes, I want to test the following:

when calling Products property is should class EntityCollectionWrapper.Load method if the products is not already loaded –IsLoaded is false- this should simulate calling to original EntityCollection<TEntity>.Load method.
When calling ProductCount method, this should trigger EntityCollectionWrapper.CreateSourceQuery method which should simulate calling to original EntityCollection<TEntity>.CreateSourceQuery method.
When calling Add method of Products property (e.g. category.Products.Add(product)) this should increase Products collection count.

Below is the declaration of CategoryTest Class:

[TestClass]
public class CategoryTest
{
	private readonly Category _category;
	private readonly Mock<EntityCollectionWrapper<IProduct, Product>>  _mockedProducts;
	public CategoryTest()
	{
		_category = new Category();
		_mockedProducts = new Mock<EntityCollectionWrapper<IProduct, Product>>(_category.ProductsInternal);
	}
	//Rest of code omitted and will be discussed later
}

As you notice in the above code line 5, there is a mocked object of EntityCollectionWrapper class that is instantiated in the constructor line 9. But how exactly I am going to set the related field in Category class? Below are the Category class implementation for ICategory interface:

public partial class Category : ICategory
{
    private EntityCollectionWrapper<IProduct,Product> _products;

    public IEntityCollection<IProduct> Products
    {
        get 
        {
            EnsureProducts();
            if (!_products.IsLoaded)
            {
                _products.Load();
            }
            return _products;
        }
    }

    public int ProductCount
    {
        get
        {
            EnsureProducts();
            return _products.CreateSourceQuery().Count();
        }
    }

    private void EnsureProducts()
    {
        if (_products == null)
        {
            _products = new EntityCollectionWrapper<IProduct, Product>(this.ProductsInternal);
        }
    }

    /// <summary>
    /// Helper method used for unit testing purpose only to set Mocked EntityCollectionWrapper
    /// to local private object _products.
    /// </summary>
    /// <param name="mockedProducts">Mock object of EntityCollectionWrapper</param>
    internal void SetMockedEntityCollection(EntityCollectionWrapper<IProduct,Product> mockedProducts)
    {
        _products = mockedProducts;
    }
}

Last method on line 40 is internal method that is used only for testing purpose to assign a mocked instance of EntityCollectionWrapper to the local private member of the same type.

Also It worth to mention that the generated EntityCollection<Product> property which called here ProductsInternal has internal access modifier, because this is also is being used internally as well as from the testing project.

Now back to CategoryTest class, I am using the following method as my test initialization method:

[TestInitialize]
public void TestInitialize()
{
	_category.SetMockedEntityCollection(_mockedProducts.Object);
}

Simply it makes a call to the internal method SetMockedEntityCollection and pass the mocked object as parameter to it. Now that I have a mocked object injected into my class I can start setup my results to continue testing.

[TestMethod]
public void Category_Products_Should_Call_EntityCollection_Load_If_ProductsInternal_Not_Loaded()
{
    _mockedProducts.SetupGet(p => p.IsLoaded).Returns(false).Verifiable();
    _mockedProducts.Setup(p => p.Load()).Verifiable();
    IEntityCollection<IProduct> products = _category.Products;

    _mockedProducts.Verify();
}

In the above code I am testing lazy loading. If the collection is not loaded Load method of the EntityCollection should be called. At line 4 I set assumption that EntityCollectionWrapper<IProduct,Product>.IsLoaded should return false. And as this property must be called I’m asking to verify that it will be called using Verifiable method. At line 5 I am asking to verify that Load method is being called. Finally line 8 when calling Verify method, all verifiable calls will be evaluated and if one of the verifiable calls never occur and exception will be thrown and the test method will fail.

The other 2 tests that I motioned earlier are below:

[TestMethod]
public void Category_ProductCount_Should_Call_EntityCollection_CreateSourceQuery()
{
    IList<Product> products = new List<Product>();
    _mockedProducts.Setup(p => p.CreateSourceQuery()).Returns(products.AsQueryable()).Verifiable();
    
    int count = _category.ProductCount;

    _mockedProducts.Verify();
}

[TestMethod]
public void Category_Add_Product_To_Products_Collection_Should_Increase_Collection_Count()
{
    _category.Products.Add(new Product());
    Assert.AreEqual(1, _category.Products.Count);
}

I think I delivered my idea here. So you can explore the attached solution for the rest of unit tests of both entities Product and Supplier. Supplier is exactly the same as Category.

I next post I will provide code for integration testing this. Just to make sure that this is really going to work with Entity Framework. For the time being, trust me it does work.

Download Sample Project.

Book Review: ASP.NET 3.5 Application Architecture and Design

mosessaur — Sat, 14 Mar 2009 13:46:50 PDT

Information about the book:

Book Title: ASP.NET 3.5 Application Architecture and Design
Book's Page: http://www.packtpub.com/application-architecture-and-design-for-asp-.net-3.5/book
Book Cover

Chapters: 9
Publisher: PACKT Publishing
Author: Vivek Thakur

Introduction:

Microsoft ASP.NET has quickly evolved to become one of the most famous platforms for developing web-based solutions. Since its first release with .Net 1.0, Microsoft has continuously added many out-of-the-box features and components, making web development easier for the end developer. As ASP.NET is part of the whole .Net Framework, it is gaining benefits of all features and technologies provided by the .Net Framework itself. With the introduction of LINQ, MS AJAX, WCF, WPF, and a lot of exciting new tools, the .NET framework has not only grown large but also flexible, in terms of the choices and options being offered to the developers.

About ASP.NET 3.5 Application Architecture and Design Book:

ASP.NET 3.5 Application Architecture and Design book is a small one (239) pages divided into 9 chapters. It is not a "pure" architecture and design guide. Rather, the goal is to show you how to design a web site in ASP.NET the correct way, focus on different design options, analyze and study what architectural options we have, and decide when to use which
architectural solution.

Although this book primarily aimed at beginner and intermediate developers, it is a good resource for experienced programmers as well. This book is not a theoretical guide on architecture and design patterns, or any other technology.

ASP.NET 3.5 Application Architecture and Design at glance:

The book contains 9 chapters as the following:

Chapter 1 Introduction to Architecture and Design. This chapter focus on Understanding architecture and design from a practical point of view as well as architectural styles. It talks about what design patterns are, what are different stages for a project lifecycle and what is the difference between tiers and layers.

Chapter 2 1-Tier 1-Layer Architecture in ASP.NET. Start diving into ASP.NET code, this chapter shows through the use of examples the default N-Tier nature of web applications, why applications based on classic inline ASP are tightly coupled and What 1-tier 1-layer architecture is? It show how to use code-behind classes in ASP.NET as another layer in the UI tier and how Data Source Controls fit into the application architecture of ASP.NET web applications. However this chapter is not a guide on how to use Data Source controls. This chapter also shows how the 1-tier, 1-layer style is tightly-coupled and is not flexible or scalable.

Chapter 3 ER Diagrams, Domain Model, and N-Layer Architecture. After learning and seeing the basic layering of the monolithic 1-tier 1-layer architectural style in action in chapter 2 and understanding that this 1-tier 1-layer architecture is the default style in ASP.NET and Visual Studio 2005/2008. This chapter talks about how to overcome the limitation of this style by further break the application code into n-layers. This chapter will teach you the 2 layer style, understanding ER diagrams, what domain model is and what are UML relationships and basics of UML. It will go through 3 layer style and discuss the drawbacks or limitations of this model. It will also talks about object data source control and where it will fit in your application design.

Chapter 4 N-Tier Architecture. Talks about n-tier architecture in ASP.NET, why it is needed and how to implement it. It also explains Data Transfer Objects and how to use them with 4-tier and 5-tier web solutions.

Chapter 5 Model View Controller. The brand new feature in ASP.NET, the ASP.NET MVC. You will learn and understand what MVC design is, and how the ASP.NET MVC framework will help you quickly implement MVC design in your web applications. Through this chapter, you'll understand the basic ASP.NET web forms Page Controller Pattern and why MVC pattern is needed.

Chapter 6 Design Patterns. As you go through the previous chapters, you'll learn about different types of design patters. In this chapter you will learn how and when to use the most common design patterns in ASP.NET such as Factory, Dependency Injection, Singleton, and others with examples.

Chapter 7 SOA and WCF. This chapter discuss what is SOA (Service oriented architecture) and why it is need, explaining the advantages of SOA for a beginner. You'll learn about SOA and web services. And then you'll learn what WCF and how to implement SOA using WCF.

Chapter 8 Database Design. You'll learn how much a well designed database is important. You'll learn about logical & physical models, what is data integrity and how to make your database designed normalized.

Chapter 9 Localization. One of the important subjects about building web application is how to localize your application. This chapter discuss what is localization and globalizations, and what are the best practices to follow while implementing globalization. Bow to build localizable ASP.NET 3.5 web application using features of ASP.NET.

Personal Opinion:

The book is a great resource for beginners and intermediate ASP.NET developers. Personally I met many web developers (ASP.NET) who know nothing about basic web application architecture & design and design patterns. I wished that there is a single crash start resource where they can learn the solid basic about this subject. I can say I finally found this resource, it is the ASP.NET 3.5 Application Architecture and Design book. Very well organized and take your through the basics step by step till you fully understand the difference between each style and where each style might fit.

May rate for this book is 4 out of 5.

Conclusion:

My recommendation for beginners ASP.NET web developers is to read this book, especially if they have no practical experience. This book is not ASP.NET How to! It is about the basics of how to architect and design ASP.NET 3.5 web based application, and what are the options available for that as well as the options provided by .Net Framework and VS.NET out of the box to ease this job.

Domain Driven Design & Test Driven Design\Development with Entity Framework Part 1.b Integration Testing for ObjectContext

mosessaur — Mon, 23 Feb 2009 00:00:26 PST

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.

[TestClass]
public class NorthwindDataContextIntegrationTest : IDisposable
{
    IDataContext _context;
    public NorthwindDataContextIntegrationTest()
    {
        _context = new NorthwindDataContext(ConfigurationManager
                    .ConnectionStrings["NorthwindDatabaseContext"]
                    .ConnectionString);
    }
    
    [TestMethod]
    public void NorthwindDataContext_CategoryDataSource_Returns_CategorySet()
    {
        Assert.IsNotNull(_context.CategoryDataSource);
    }
    
    [TestMethod]
    public void NorthwindDataContext_ProductDataSource_Returns_ProductSet()
    {
        Assert.IsNotNull(_context.ProductDataSource);
    }

    [TestMethod]
    public void NorthwindDataContext_SupplierDataSource_Returns_SupplierSet()
    {
        Assert.IsNotNull(_context.SupplierDataSource);
    }
    
    [TestMethod]
    public void NorthwindDataContext_Insert_Should_Change_Instance_EntityState_To_Added()
    {
        var category = Category.CreateCategory(1, "New Category");
        
        _context.InsertOnSubmit("CategorySet",category);

        Assert.AreEqual(category.EntityState, System.Data.EntityState.Added);
    }

    [TestMethod]
    public void NorthwindDataContext_Delete_Should_Change_Instance_EntityState_To_Deleted()
    {
        var category = _context.CategoryDataSource.FirstOrDefault();
        
        _context.DeleteOnSubmit(category);

        Assert.AreEqual(category.EntityState, System.Data.EntityState.Deleted);
    }
    
    public void Dispose()
    {
        ((NorthwindDataContext)_context).Dispose();
    }
}

Download Source Code.

Domain Driven Design & Test Driven Development\Design with Entity Framework Part 1.b, Review

mosessaur — Sat, 21 Feb 2009 10:43:18 PST

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.

Responsibility of ObjectContext:

After reviewing my code and in previous post, I found that I am giving too much responsibilities to ObjectContext. Which will simply make my Repositories abstract wrappers for ObjectContext. On the other hand the benefit is very low. My target was to decouple repository and EF! And the benefit cannot be mentioned. Because if I want to achieve decoupling that means I can use same IDataContext interface with another Data Access Helper class such as LINQ to SQL context or any other Data Access produced by any ORM. And this might not be possible.

So I decided to put a limitation to my IDataContext and make it coupled with EF. Then the main usage of IDataContext would be for TDD support.

I would like to refer to a great post made by Kazi about how to build 100% Testable LINQ to SQL Repositories. I am actually applying his idea on EF.

I will not talk about Repositories responsibilities, because they are clearly defined in DDD. But there is not harm if you made your Data Access Layer generated from any ORM coupled with Repositories. It will ease the development and keep everything be in the right direction.

Code Updated:

Because I changed my design, I've updated my code to remove few methods and simplify IDataContext.

public interface IDataContext
{
    IQueryable<Category> CategoryDataSource { get; }
    IQueryable<Product> ProductDataSource { get; }
    IQueryable<Supplier> SupplierDataSource { get; }

    IQueryable<T> GetQueryable<T>(string queryString) 
        where T: EntityObject;

    void AddObject<T>(string entitySetName, T entity) 
        where T : EntityObject;

    void InsertOnSubmit<T>(string entitySetName, T entity) 
        where T : EntityObject;
    
    void DeleteOnSubmit<T>(T entity) 
        where T : EntityObject;
    
    void SubmitChanges();
}

public partial class NorthwindDataContext : IDataContext
{
    private IQueryable<Category> _categorySet;
    private IQueryable<Product> _productSet;
    private IQueryable<Supplier> _supplierSet;
    
    public IQueryable<Category> CategoryDataSource
    {
        get
        {
            if (_categorySet == null)
            {
                _categorySet = GetQueryable<Category>("[CategorySet]");
            }
            return _categorySet;
        }
    }
    
    public IQueryable<Product> ProductDataSource
    {
        get
        {
            if (_productSet == null)
            {
                _productSet = GetQueryable<Product>("[ProductSet]");
            }
            return _productSet;
        }
    }
    
    public IQueryable<Supplier> SupplierDataSource
    {
        get
        {
            if (_supplierSet == null)
            {
                _supplierSet = GetQueryable<Supplier>("[SupplierSet]");
            }
            return _supplierSet;
        }
    }

    public virtual IQueryable<T> GetQueryable<T>(string queryString) where T : EntityObject
    {
        return base.CreateQuery<T>(queryString);
    }

    public void InsertOnSubmit<T>(string entitySetName, T entity)
        where T : EntityObject
    {
        AddObject<T>(entitySetName, entity);
    }

    public void DeleteOnSubmit<T>(T instance)
        where T : EntityObject
    {
        DeleteObject(instance);
    }

    public virtual void AddObject<T>(string entitySetName, T entity)
        where T : EntityObject
    {
        base.AddObject(entitySetName, entity);
    }
    
    public new virtual void DeleteObject(object instance)
    {
        base.DeleteObject(instance);
    }
    
    public void SubmitChanges()
    {
        base.SaveChanges(true);
    }
}

Unit Test Code:

[TestClass]
public class NorthwindDataContextTest
{
    private readonly Mock<NorthwindDataContext> _context;
    private readonly List<Category> _categories;
    private readonly List<Product> _products;
    private readonly List<Supplier> _suppliers;
    public NorthwindDataContextTest()
    {
        _context = new Mock<NorthwindDataContext>(ConfigurationManager
                   .ConnectionStrings["NorthwindDataContext"]
                   .ConnectionString);
        _categories = new List<Category>();
        _products = new List<Product>();
        _suppliers = new List<Supplier>();
    }

    [TestMethod]
    public void NorthwindDataContext_CategoryDataSource_Should_Call_GetQueryable()
    {
        _context.Expect(c => c.GetQueryable<Category>("[CategorySet]"))
                .Returns(_categories.AsQueryable())
                .Verifiable();

        Assert.IsNotNull(_context.Object.CategoryDataSource);

        _context.Verify();
    }

    [TestMethod]
    public void NorthwindDataContext_ProductDataSource_Should_Call_GetQueryable()
    {
        _context.Expect(c => c.GetQueryable<Product>("[ProductSet]"))
                .Returns(_products.AsQueryable())
                .Verifiable();

        Assert.IsNotNull(_context.Object.ProductDataSource);

        _context.Verify();
    }

    [TestMethod]
    public void NorthwindDataContext_SupplierDataSource_Should_Call_GetQueryable()
    {
        _context.Expect(c => c.GetQueryable<Supplier>("[SupplierSet]"))
                .Returns(_suppliers.AsQueryable())
                .Verifiable();

        Assert.IsNotNull(_context.Object.SupplierDataSource);
        
        _context.Verify();
    }

    [TestMethod]
    public void NorthwindDataContext_Insert_Should_Call_AddObject()
    {
        var category = Category.CreateCategory(1, String.Empty);

        _context.Expect(c => c.AddObject("[CategorySet]",category)).Verifiable();

        _context.Object.InsertOnSubmit("[CategorySet]", category);

        _context.Verify();
    }

    [TestMethod]
    public void NorthwindDataContext_Delete_Should_Call_DeleteObject()
    {
        var category = Category.CreateCategory(1, String.Empty);

        _context.Expect(c => c.DeleteObject(category)).Verifiable();

        _context.Object.DeleteOnSubmit(category);

        _context.Verify();
    }
}

Conclusion:

EF is not testable by nature, you'll have to find a way to do unit testing independent of EF. That is why I am keeping updating my code till I reach to a an ideal way. Maybe not the best way but at least a method that will ease this job for the time being. I think it might also result in writing your own EF code generator using EdmGem.

I've update the code on this post, you can download it here.

Domain Driven Design & Test Driven Development\Design with Entity Framework, Part 1.a Refactoring & Unit Testing

mosessaur — Tue, 10 Feb 2009 15:49:55 PST

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

Refactoring of IDataContext and Models:

After some discussion with Davy Landman and getting some feedback from him. I made some refactoring to IDataContext although me an him have different ideas few conflicts. So basically here is what I need from IDataContext to support:

Being able to retrieve all records of Categories, Products & Supplier
Being able to filter these entities by unique identifier to return single record.
Being able to register new record for insertion or deletion.
Being able to persist changes to the underlying data source.

The above list is not the only features I need, in future it must grow, like being able to filter Products by category and so on.

I hear some of you saying, What! this is the job of repository classes to build queries and perform data access. and I will answer yes and I totally agree, but I provide IDataContext as a huge repository of queries that is actually wrapped by Repositories. I think this concept is applicable with some ORM tools such as EF and LINQ to SQL. But might not work for other things such as classical Data Access Layers and NHibernate. So simply I consider IDataContext part of repository classes.

The implementation of IDataContext which is NorthwindDataContext class includes some helper methods & properties to assist me to work with EF and being able to test it. But generally I am hiding most the features provided by EF generated code with these methods & properties. Because simply that generated code is not testable and you cannot use to set expectations when you start to use mocking.

Below is the class diagram of my refactored model with data access layer helper:

Also I zoomed on NorthwindDataContext class and provided the following diagram with comments about 2 helper methods:

Here is the code of GetEnumrable & GetFilteredDataSource methods with explanation of each method's role :

/// <summary>
/// Used as helper method to provide casting from EDM primative data type 
/// (generated model entity) such Category to model Interface such ICategory 
/// which is implemented by the generated EDM entity class.
/// </summary>
/// <typeparam name="I">Type of the model interface</typeparam>
/// <typeparam name="E">
/// Type of the EF primative data type (generated model entity)
/// "E" (model entity) must implement "I" (model interface)
/// </typeparam>
/// <param name="datasource">Data source to be filtered</param>
/// <param name="filter">Filter expression used to filter datasource</param>
/// <returns>IEnumrable of I (model interface)</returns>
private static IEnumerable<I> GetEnumerable<I, E>(IQueryable<E> datasource, Expression<Func<E, bool>> filter)
 where I : class, IEntity
 where E : class, I
{
 var filteredQry = (filter != null) ? datasource.Where(filter) : datasource;
 foreach (var item in filteredQry)
     yield return item as I;
}

/// <summary>
/// Takes as a parameter Linq filter Expression to be used to filter data source set
/// such as CategorySet. 
/// This will help to provide filters that will perform filtering on underlying 
/// data source side and not in memory filtering using LINQ to Objects.
/// This method calls GetEnumerable<I, E> providing it with the correct data source set.
/// </summary>
/// <typeparam name="I">Type of the model interface</typeparam>
/// <typeparam name="E">
/// Type of the EF primative data type (generated model entity)
/// "E" (model entity) must implement "I" (model interface)
/// </typeparam>
/// <param name="datasource">Data source to be filtered</param>
/// <param name="filter">Filter expression used to filter datasource</param>
/// <returns>IQueryable of I (model interface)</returns>
private IQueryable<I> GetFilteredDataSource<I, E>(Expression<Func<E, bool>> filter)
 where I : class, IEntity
 where E : class, I
{
 IQueryable<E> queryable = null;

 if (typeof(I) == typeof(ICategory))
     queryable = this.CategoryTable as IQueryable<E>;
 else if (typeof(I) == typeof(IProduct))
     queryable = this.ProductTable as IQueryable<E>;
 else if (typeof(I) == typeof(ISupplier))
     queryable = this.SupplierTable as IQueryable<E>;

 return GetEnumerable<I, E>(queryable, filter).AsQueryable() as IQueryable<I>;
}

Now if I wanted to filter Category set data source by Category Id I shall use GetFilteredDataSource by a way or another. That is why I am using in FindXxxById methods as the following:

public ICategory FindCategoryById(int id)
{
 return this.GetFilteredDataSource<ICategory, Category>(c => c.Id == id).FirstOrDefault();
}

public IProduct FindProductById(int id)
{
 return this.GetFilteredDataSource<IProduct, Product>(c => c.Id == id).FirstOrDefault();
}

public ISupplier FindSupplierById(int id)
{
 return this.GetFilteredDataSource<ISupplier, Supplier>(c => c.Id == id).FirstOrDefault();
}

Coding Testable EF ObjectContext Class:

Before starting this point, let me clarify what does Testable means. Testable means being able to write Unit Test code that can test your coded independent of the environment, database or anything similar. And being able to mock your classes. Simply being able to write Unit Tests that follow the guide lines mentioned in my earlier post.

That was my target for NorthwindDataContext class, is being able to test it independent of the database, and confirm the success of my test by doing integration test that also success.

Someone would say and why I want to test something that is already tested (by Microsoft)? Well because later you'll need to test classes that depends on this class. If you used the auto generated EF code as it is you'll not be able to set expectations out of it to be able to test independent of the database.

The auto generated code is not testable, because it requires to hit the database and you cannot mock it. In order to be able to stay way of database you need to have an alternative. The common alternative is in memory storage using Lists.

Using generated EntitySet types such as CategorySet properties will require database. To workaround this I created few helper public virtual properties that wrap auto generated EntitySets such as CategorySet as the following:

/// <summary>
/// Return EF Coupled IQueryable of Category. Used for testing purpose only
/// </summary>
public virtual IQueryable<Category> CategoryTable
{
 get{ return this.CategorySet; }
}
/// <summary>
/// Return EF Coupled IQueryable of Product. Used for testing purpose only
/// </summary>
public virtual IQueryable<Product> ProductTable
{
 get{ return this.ProductSet; }
}
/// <summary>
/// Return EF Coupled IQueryable of Supplier. Used for testing purpose only
/// </summary>
public virtual IQueryable<Supplier> SupplierTable
{
 get{ return this.SupplierSet; }
}

Now why these helper properties are virtual public. Public because I want to be able to access them throw my unit test classes. Virtual because Moq will require these properties to be virtual in order to be able to override them to return my specified expectations. Same concept is applied to some public methods such AddObject and DeleteObject methods. But because these properties or methods are not interface based; so they will not be accessible through repositories as I'll show on my upcoming posts.

The above properties are invoked through GetFilteredDataSource method.

Writing Unit Test for EF ObjectContext Class:

In TDD is supposed to write your tests first, fail them and start fix what is broken and make your code run. Then do refactoring over and over to formalize your code. My first test attempt will fail because of NotImplementedException thrown by IDataContext methods in NorthwindDataContext class. My test basically want to test the following:

Calling IDataContext (Categories,Products or Suppliers) properties should not return null.
Calling IDataContext FindXxxById methods should return correct Xxx entity.
Calling IDataContext Insert should call AddObject Method of NorthwindDataContext to insure that the object is being added to proper Entity Set and prepared for persistence.
Calling IDataContext Delete should call DeleteObject Method of NorthwindDataContext to insure that the object is being marked for deletion.

I am using Moq to assist me in my TDD. In this attempt I will need a mock instance of NorthwindDataContext to simulate its work independent of the underlying database. Also I am initializing few lists to act as in memory storage.

private readonly Mock<NorthwindDataContext> _context;
private readonly List<Category> _categories;
private readonly List<Product> _products;
private readonly List<Supplier> _suppliers;
public NorthwindDataContextTest()
{
    _context = new Mock<NorthwindDataContext>(ConfigurationManager
                                             .ConnectionStrings["NorthwindDataContext"]
                                             .ConnectionString);
    _categories = new List<Category>();
    _products = new List<Product>();
    _suppliers = new List<Supplier>();
}

On line 7 to 9 I am initializing new mock instance of NorthwindDataCotext. I am getting a connection string from application configuration file. you might ask why I would need a connection string. Actually this is a must thing in order to be able to load your EDM model. If you didn't provide this connection string the mocking will fail. The connection string in this test just specify the path of CSDL, SSDL and MSL. In my case they are embedded resources:

<configuration>
 <connectionStrings>
  <add name="NorthwindDataContext" 
       connectionString="metadata=res://*/Edm.Northwind.csdl|res://*/Edm.Northwind.ssdl|res://*/Edm.Northwind.msl;provider=System.Data.SqlClient;"
       providerName="System.Data.EntityClient" />
 </connectionStrings>
</configuration>

Writing Test Initialization with Visual Studio.Net Unit Testing:

As I am using VS.Net unit testing tools I am using the provided unit testing facilities. Such as Test Initialization feature. This is just a method marked with TestInitialize attribute as the following:

[TestInitialize]
public void TestInitialize()
{
    _context.ExpectGet(c => c.CategoryTable)
			.Returns(_categories.AsQueryable());
    
	_context.ExpectGet(c => c.ProductTable)
			.Returns(_products.AsQueryable());
    
	_context.ExpectGet(c => c.SupplierTable)
			.Returns(_suppliers.AsQueryable());
}

I am using the mocked NorthwindDataContext to set expectation to the helper properties I mentioned earlier. Again to be able to set expectations with Moq you'll need public virtual methods or properties. So Whenever a call is made to CategoryTable or ProductTable or SupplierTable the specified expectation for each one should be returned.

Now I want to test IDataContext properties (Categories, Products and Suppliers):

[TestMethod]
public void NorthwindDataContext_Categories_Returns_Category_Set()
{
    Assert.IsNotNull(_context.Object.Categories);
}
[TestMethod]
public void NorthwindDataContext_Products_Returns_Product_Set()
{
    Assert.IsNotNull(_context.Object.Products);
}
[TestMethod]
public void NorthwindDataContext_Suppliers_Returns_Supplier_Set()
{
    Assert.IsNotNull(_context.Object.Suppliers);
}

Hint: Unit test method in VS.Net are marked with TestMethod Attribute. Every time one of the test method being call TestInitialize Method will be called first as well as test class constructor.

I wish to trace the call of the above code. _context.Object will return a mocked instance of NorthwindDataContext. When calling Categories property this property invokes GetFilteredDataSource method which in turn calls CategoryTable helper property. When CategoryTable property is called it will return the expectation I specified in TestInitialize method. Same thing is applied for the other properties.

Time to test filtering methods such as FindCategoryById. I write test for such methods by preparing data to test with, then set my expectation. Finally perform tested method call and assert returned results, just as the following:

[TestMethod]
public void NorthwindDataContext_FindCategoryById_Returns_Correct_Category()
{
 //Prepare test data.
 for (int i = 1; i < 11;i++ )
     _categories.Add(Category.CreateCategory(i, String.Empty));

 //Get existing Id.
 int id = _categories[0].Id;

 //Set Expectation
 _context.ExpectGet(c => c.CategoryTable).Returns(_categories.AsQueryable());

 //Perform Test
 var category = _context.Object.FindCategoryById(id);

 //Assert
 Assert.IsNotNull(category);
 Assert.AreEqual(category.Id, id);
}

Note that I am testing single thing per unit test method. That doesn't mean you should perform single assert. In the above method I am testing one then but doing 2 asserts, one to ensure that the returned result is not null and the other assert to ensure that the returned result is the desired one.

My final test is to test Insert and Delete method. Actually in these tests I just want to check if AddObject or DeleteObject methods are being called. These helper methods uses internally the EF generated code to add object to the context or mark it for deletion. I don't want to test the underlying EF generated code, I just want to test mine.

[TestMethod]
public void NorthwindDataContext_Insert_Should_Call_AddObject()
{
 var category = Category.CreateCategory(1, String.Empty);

 _context.Expect(c => c.AddObject(category)).Verifiable();

 _context.Object.Insert(category);

 _context.Verify();
}

On line 6 I am setting my expectation as a call to AddObject method. And using Moq features I am asking to verify this call using Verifiable method of the mocked object. On line 10 I am calling Verify method of the mocked NorthwindDataContext. This method will verify that AddObject method is being called. If not the test will fail.

After running my test I got them all Green.That was a happy ending. This code should run on your machine and produce green results as well. You can download it and review the code and get me with some feedback and enhancements.

I would like to thank Davy Landman for his valuable ideas and thoughts and the references he provided me about DDD. I am new to DDD & TDD and I thought the best way to learn them is to share my thoughts with others, making mistakes and let somebody else correct me. So feel free to comment and provide me with more resources and ideas.

As this post already grow long I will keep my integration test for the next post. Where I will show that my assumptions and expectations during TDD unit testing applies also on my Integration testing.

Keep tuned.

Domain Driven Design & Test Driven Design With Entity Framework, Part 1 Building Domain Object Model

mosessaur — Wed, 04 Feb 2009 16:38:23 PST

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.

I started to create my Domain Object using Entity Framework. My Entity Data Model looks like the below diagram:

I'm not done yet. I thought that just using my generated code is not enough. And I want to abstract my Domain Object as much as possible incase I want to use different tool other than Entity Framework such as LINQ to SQL.

So I created 3 contracts (interfaces), that actually represents my Domain Objects: ICategory, IProduct and ISupplier. These contracts has parent interface called IEntity that has only one property called Id. Assuming that all my Domain Objects should have a unique key property of type integer and called Id.

I made my generated models to implement those interfaces (thanks to partial classes). In fact those interfaces contains exactly same property names and types as specified in the above models. Except that I renamed the navigation properties in the generated models to include the word Internal such as ProductsInternal navigation property in Category concrete data model class.

Below are the definition of each interface:

public interface IEntity
{
    int Id { get; }
}

public interface ICategory : IEntity
{
    string CategoryName { get; set; }
    string Description { get; set; }
    byte[] Picture { get; set; }
    IQueryable<IProduct> Products { get; }
}

public interface IProduct : IEntity
{
    string ProductName { get; set; }
    string QuantityPerUnit { get; set; }
    decimal? UnitPrice { get; set; }
    short? UnitsInStock { get; set; }
    short? UnitsOnOrder { get; set; }
    short? ReorderLevel { get; set; }
    bool Discontinued { get; set; }
    ICategory Category { get; }
    ISupplier Supplier { get; }
}

public interface ISupplier : IEntity
{
    string CompanyName { get; set;}
    string ContactName { get; set; }
    string ContactTitle { get; set; }
    string Address { get; set; }
    string Country { get; set; }
    string City { get; set; }
    string Region { get; set; }
    string PostalCode { get; set; }
    string Phone { get; set; }
    string Fax { get; set; }
    string HomePage { get; set; }
    IQueryable<IProduct> Products { get; }
}

I would like to clarify few points about the above code. As you notice on lines 11, 23, 24 and 40. These lines of code define navigation properties. For example ICategory domain object interface has a navigation property IQueryable<IProduct> Products that retrieves all products related to a specific category. I made this to be independent of the under laying generated code by Entity Framework. This is actually abstraction and removing dependency between your Domain Object Definitions and its implementations. The definitions should define what these models should contain and do. The implementation should specify the how. Your concrete models might be coupled with certain technology, as in my case. My concrete models are Entity Framework Models.

Entity Framework as Data Access Layer:

Entity Framework provide Data Services classes that I will use as my data access layer assets. For example the generated ObjectContext class, this is actually acts as my proxy to the underlying datasource and called entity container by Entity Framework Schema. But Entity Framework doesn't support -in version 1- persistence ignorance! Which will make working with my Domain Object Model interfaces hard and may be impossible. Because for example the generate ObjectContext class doesn't have anything that would return a result set of ICategory. And guess what you'll not be able to cast ObjectQuery<Category> to IQueryable<ICategory>.

Take this as an example the generate NorthwindDataContext has a property called CategorySet. This property returns ObjectQuery<Category>. You might think of calling this property like this:
context.CategorySet.Cast<ICategory>().AsQueryable();
But this is simply will not work and will throw an exception as Cast extension method will only work if you are casting to correct generate Entity Models primitive types.

Another issue calling CategorySet property or calling CreateQuery<T> method of the base ObjectContext class would result in creating a query that will require hitting the database when starting to iterate through the results. This issue violates one of the guide lines of performing TDD which is to be independent of the working environment by simulating environmental dependencies such as databases, file systems, networks, queues etc...

To over come these issues simply I created another interface that include basic data access functionality. I learned this idea from Kigg the open source project that is running live on http://dotnetshoutout.com/. This project apply the same idea on Linq To SQL context object class.

I called the interface IDataContext and defined the basic operations I will need in this interface:

public interface IDataContext
{
 IQueryable<ICategory> Categories { get; }
 IQueryable<IProduct> Products { get; }
 IQueryable<ISupplier> Suppliers { get; }
    
 IQueryable<TInterface> GetDataSource<TInterface, TEntity>(Func<TEntity, bool> filterExpression)
     where TInterface : class, IEntity
     where TEntity : class;

 TEntityInterface GetEntityById<TEntityInterface>(int id) 
     where TEntityInterface : class, IEntity;

 void Insert<TEntityInterface>(TEntityInterface instance) 
     where TEntityInterface : class, IEntity;
    
 void Delete<TEntityInterface>(TEntityInterface instance) 
     where TEntityInterface : class, IEntity;
    
 void SubmitChanges();
}

Again the generated ObjectContext class by Entity Framework should implement this interface. Below is the implementation of IDataContext:

public partial class NorthwindDataContext : IDataContext
{
 public static IEnumerable<TInterface> GetEnumerable<TInterface, TEntity>(IQueryable<TEntity> query, Func<TEntity, bool> filter)
  where TInterface : class, IEntity
  where TEntity : class
 {
  var filteredQuery = (filter != null) ? 
	(from item in query select item).Where(filter) : query;
  foreach (var item in filteredQuery)
  {
   yield return item as TInterface;
  }
 }

 public virtual IQueryable<Category> CategoryTable
 {
  get{return this.CategorySet;}
 }
 public virtual IQueryable<Product> ProductTable
 {
  get{return this.ProductSet;}
 }
 public virtual IQueryable<Supplier> SupplierTable
 {
  get{return this.SupplierSet;}
 }
 
 public IQueryable<ICategory> Categories
 {
  get
  {
   return this.GetDataSource<ICategory, Category>(null);
  }
 }
    
 public IQueryable<IProduct> Products
 {
  get
  {
   return this.GetDataSource<IProduct, Product>(null);
  }
 }
    
 public IQueryable<ISupplier> Suppliers
 {
  get
  {
   return this.GetDataSource<ISupplier, Supplier>(null);
  }
 }

 public IQueryable<TInterface> GetDataSource<TInterface, TEntity>(Func<TEntity, bool> filter)
  where TInterface : class, IEntity
  where TEntity : class
 {
  IQueryable<TEntity> queryable = null;
  if (typeof(TInterface) == typeof(ICategory))
     queryable = this.CategoryTable as IQueryable<TEntity>;                
  if (typeof(TInterface) == typeof(IProduct))
     queryable = this.ProductTable as IQueryable<TEntity>;
  if (typeof(TInterface) == typeof(ISupplier))
     queryable = this.SupplierTable as IQueryable<TEntity>;

  return GetEnumerable<TInterface, TEntity>(queryable, filter).AsQueryable() as IQueryable<TInterface>;
 }
    
 public TEntity GetEntityById<TEntity>(int id) 
  where TEntity : class, IEntity
 {
  if (typeof(TEntity) == typeof(ICategory))
  {
   return this.GetDataSource<ICategory,Category>(c => c.Id == id).SingleOrDefault() as TEntity;
  }
  else if (typeof(TEntity) == typeof(IProduct))
  {
   return this.GetDataSource<IProduct,Product>(c => c.Id == id).SingleOrDefault() as TEntity;
  }
  else if (typeof(TEntity) == typeof(ISupplier))
  {
   return this.GetDataSource<ISupplier, Supplier>(c => c.Id == id).SingleOrDefault() as TEntity;
  }
  else
   return null;
  }

 public void Insert<TEntity>(TEntity instance) 
  where TEntity : class, IEntity
 {
  AddObject<TEntity>(instance);
 }
 public void Delete<TEntity>(TEntity instance)
  where TEntity : class, IEntity
 {
  DeleteObject(instance);
 }
 public virtual void AddObject<TEntity>(TEntity instance) 
  where TEntity : class, IEntity
 {
  Type type = typeof(TEntity);
  if (type == typeof(ICategory))
  {
   this.AddToCategorySet(instance as Category);
  }
  else if (type == typeof(IProduct))
  {
   this.AddToProductSet(instance as Product);
  }
  else if (type == typeof(ISupplier))
  {
   this.AddToSupplierSet(instance as Supplier);
  }
 }
    
 public new virtual void DeleteObject(object instance)
 {
  base.DeleteObject(instance);
 }
    
 public void SubmitChanges()
 {
  base.SaveChanges(true);
 }
}

An important thing to note, now after implementing IDataContext, from my code I should use NorthwindDataContext as IDataContext. Which means my consumer application which could be a Repository class or anything else should not know anything about NorthwindDataContext and be totally independent of it.

Using NorthwindDataContext as my data access layer through IDataContext is something that can be specified using Dependency Injection.

Start Updated Content
I would like to explain 2 methods above which are IEnumerable<TInterface> GetEnumerable<TInterface, TEntity>(IQueryable<TEntity> query, Func<TEntity, bool> filter) and IQueryable<TInterface> GetDataSource<TInterface, TEntity>(Func<TEntity, bool> filter)...

GetEnumerable method is helper method, I used it to overcome casting limitations in LINQ to Entities. This method takes IQueryable<TEntity> as a parameter. TEntity is supposed to be the concrete model class while IQueryable<TEntity> will be actually ObjectQuery<TEntity>. This method is used by XxxDataSource properties. It will help me much in testing my Data Access Layer as I will show in the next part soon.

About GetDataSource method, this one also to overcome LINQ to Entities limitations. In fact in implementation GetDataSource makes call to GetEnumerable and pass a filter expression to it. Someone would say why Filter as you could use property Categories and build a LINQ statement over it and that is it, something like context.Categories.Where(c=>c.Id == 1); Well, I highly recommend to review Davy Landman comment on this post which shows that the code snippet context.Categories.Where(c=>c.Id == 1) would perform filter in memory and not on database side. Maybe I should call this method GetFilteredDataSource.
End Updated Content

I didn't complete the implementation of my domain model objects, basically the navigation properties. There are different ideas to implement them so I will keep that to be done later to differentiate between different approaches I have in mind.

What about TDD first?!

You might ask why I didn't start with TDD as supposed?! Well, I had an idea that my domain object should be ready before starting writing testing code! Someone would say write test and then refactor! I say 2 faces one coin. I made my design, and I will write its Test every time I finish part of it. Now that I finished this part, I would start writing my unit test code. In next part I will talk about Unit Testing with VS.Net tools and Moq. Applying TDD to my design to ensure that my code works fine with my expectations. And later I will do another unit testing for integration to ensure that both TDD and Integration Testing where both built on the correct assumptions.

Moq will help me to achieve 3 guide lines:

Separates or simulates environmental dependencies such as databases, file systems, networks, queues, and so on. Tests that exercise these will not run fast, and a failure does not give meaningful feedback about what the problem actually is.
Runs and passes in isolation. If the tests require special environmental setup or fail unexpectedly, then they are not good unit tests. Change them for simplicity and reliability. Tests should run and pass on any machine.
Often uses stubs and mock objects. If the code being tested typically calls out to a database or file system, these dependencies must be simulated, or mocked. These dependencies will ordinarily be abstracted away by using interfaces

Moq will help me to set expectations for my returning results of certain methods. For example GetEnumerable method I mentioned above should return IEnumerable<TInterface>. I can simulate its operation using Moq and set an expectation to its call where expected and also define the return results. To simulate database results I will use in memory collections which I will specify as return results whenever possible with the assist of Moq. We will look at what Moq can provide us in my next post.

You can download my initiative project and Stay Tuned for the upcoming part.

First Steps toward Test Driven Design\Development

mosessaur — Tue, 27 Jan 2009 17:33:06 PST

Introduction:

I'm totally new to TDD world. I saw many sample open source projects that based on TDD and DDD but I explored only 2 of them, the MVC Storefront and Kigg (see it live). I was very lucky actually to go deep with Kigg source code and I found it one of the most clean and testable code I ever seen. With out single line of comment you can understand what this code is doing. Special thanks to Kazi Mansur Rashid every member of this project for such great work.

Quotes:

This encourage me to start practically learning TDD and apply it. So I started to search about TDD. In the following few lines I am going to list few quotes I caught from different sources:

"Test-driven development (TDD) is a software development technique that uses short development iterations based on pre-written test cases that define desired improvements or new functions. Each iteration produces code necessary to pass that iteration's tests. Finally, the programmer or team refactors the code to accommodate changes. A key TDD concept is that preparing tests before coding facilitates rapid feedback changes. Note that test-driven development is a software design method, not merely a method of testing" -Source: Wikipedia-

"The first step is to quickly add a test, basically just enough code to fail. Next you run your tests, often the complete test suite although for sake of speed you may decide to run only a subset, to ensure that the new test does in fact fail. You then update your functional code to make it pass the new tests. The fourth step is to run your tests again. If they fail you need to update your functional code and retest. Once the tests pass the next step is to start over (you may first need to refactor any duplication out of your design as needed, turning TFD into TDD)." -Source: agiledata.org, Introduction to Test Driven Design (TDD)-

"Test-driven development (TDD) is an advanced technique of using automated unit tests to drive the design of software and force decoupling of dependencies. The result of using this practice is a comprehensive suite of unit tests that can be run at any time to provide feedback that the software is still working. This technique is heavily emphasized by those using Agile development methodologies. The motto of test-driven development is "Red, Green, Refactor. Where Red: Create a test and make it fail, Green: Make the test pass by any means necessary. Refactor: Change the code to remove duplication in your project and to improve the design while ensuring that all tests still pass" -Source: MSDN, Guidelines for Test-Driven Development by Jeffrey Palermo-

My thoughts:

TDD isn't something new, but lately there was a loud talks around the community about it. Anyway after reading the above introduction quotes, I start to compare them. They are all agree you start by writing your test scenarios (coding them). Then you run them to fail. Later you start the iteration of fixing your code to make it pass the test. And finally you do refactoring. Maybe the word finally isn't the correct word, for me refactoring will be an occurring task that you'll keep doing to optimize your code and keep it clean.

One good thing about TDD is that your code will be CLEAN. I tried it myself and soon I'll share my code which I made against Entity Framework. My learning source was Kigg.

TDD & Entity Framework:

While I was trying to write tests for my Entity Data Model, I realized that my tests will require to hit the database!! Which is acceptable in case I am doing integration testing. So I had to find another way to apply TDD with EF. Kigg was the key for the solution because it does the same with LINQ to SQL, However, EF and LINQ to Entities is different than LINQ to SQL. Many things that are supported and expected work with LINQ to SQL and LINQ to Object just don't fit with LINQ to Entities. You can have read my posts regarding such not supported features in LINQ to Entities.

Guidelines listed at "Guidelines for Test-Driven Development" by Jeffrey Palermo made my understand to Unit testing in TDD clear. I am going to list few of these guidelines but I hardly recommend that you have a look at them because they aren't too much:

Separates or simulates environmental dependencies such as databases, file systems, networks, queues, and so on. Tests that exercise these will not run fast, and a failure does not give meaningful feedback about what the problem actually is.
Runs and passes in isolation. If the tests require special environmental setup or fail unexpectedly, then they are not good unit tests. Change them for simplicity and reliability. Tests should run and pass on any machine.
Often uses stubs and mock objects. If the code being tested typically calls out to a database or file system, these dependencies must be simulated, or mocked. These dependencies will ordinarily be abstracted away by using interfaces.
Clearly reveals its intention. Another developer can look at the test and understand what is expected of the production code.

That was all for this post, soon I'll start to post about TDD & DDD with samples. And I will show how to follow TDD while working with Entity Framework and being independent of it. The above guidelines where like magic words to me. Keep tuned.