Moses' Blog

Silverlight 3 is out with SDK and Tools with useful links

mosessaur — Fri, 10 Jul 2009 19: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 13: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 10: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 12: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 15: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 10: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 19: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 14: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 14: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 14: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 01: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 11: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 16: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 17: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 18: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.

MosesOfEgypt new Theme by JankoAtWrapSpeed

mosessaur — Tue, 20 Jan 2009 13:44:31 PST

Before completing one year of running this blog, I celebrate the last month of the first year of this blog by deploying my new theme create by JankoAtWrapSpeed.com. Thank you Janko.

Actually Janko created a lovely themes pack for BlogEngine.Net. He branded MosesOfEgypt.Net with his piece art theme. I like the dark theme especially that man standing front of the moon, I think Janko has a vision about it

Any way I hope you all like the new theme as I do.

Username Availability Validator AJAX Control, Release Demo

mosessaur — Sun, 04 Jan 2009 13:07:47 PST

Back in September last year (2008), I posted a demo about Username Availability Validator Control. This control developed by the community on a contest initiated by Dave Ward on August 2008 as I remember. At that time the control was in beta.

On October 2008 the control was released to public on its first version. And finally I wrote a a very simple documentation on the project Wiki.

In this post I am going to update my previous demo as well as provide new feature on the control which is SuccessMessage property to be displayed if the Username is available. This update is not available so far on project at CodePlex. This is a private update which I provided on this post only. [View Demo]

In my previous post about this subject someone asked how to apply styles similar to the ones provided by Dave himself on his post "ASP.NET AJAX username availability check". It was pretty simple to apply it using Style Sheets. Here is the updated markup of the control to use CssClass property:

<encosia:UsernameAvailabilityValidator 
	ControlToValidate="UserName"
	ValidationGroup="CreateUserWizard"
	CssClass="taken"
	ErrorMessage="Taken"
	KeyPressDelay="500"
	MinimumLength="5" 
	ServiceMethod="IsUsernameAvailable"
	ServicePath="~/MembershipService.asmx"
	ValidateOnKeyPress="True"
	Display="Static"
	runat="server"/>

As you noticed on line 4 I set CssClass property to 'taken', here is the style for the 'taken' CssClass:

.taken
{
    padding-left:22px;
    padding-bottom:3px;
    background-repeat:no-repeat;
    background-image: url(../img/taken.gif);
    color:Red;
}

What I want to show here is that it is as simple as creating Style Sheet and set a background-image property and configure it properly.

As I mentioned earlier, I updated the control to implement SuccessMessage property with SuccessCssClass. We discussed SuccessMessage & SuccessCssClass on the project discussion but they were taken off before the release of the first version. And so I decided to try it personally and gain feedback before merge it to the project original source code. I had to override the basic Render method of the server control to have more control over the rendered HTML and provide another span to display SuccessMessage and apply SuccessCssClass

You can view the demo to see this working in real life example.

<encosia:UsernameAvailabilityValidator 
	ControlToValidate="UserName"
	ValidationGroup="CreateUserWizard"
	CssClass="taken"
	SuccessCssClass="available"
	Text="Taken"
	ErrorMessage="Taken"
	SuccessMessage="Available"
	KeyPressDelay="500"
	MinimumLength="5" 
	ServiceMethod="IsUsernameAvailable"
	ServicePath="~/MembershipService.asmx"
	ValidateOnKeyPress="True"
	Display="Static"
	runat="server"/>

You can download the full solution to explore the code. Hopefully soon it will be added to the original project source control. Mainly I updated both Server Control & Client Control to manage showing and hiding ErrorMessage or SuccessMessage.

Apply Expand All and Collapse All to Collapsible Panels in ASP.NET AJAX and jQuery

mosessaur — Mon, 22 Dec 2008 00:00:45 PST

I got many feedbacks in my previous posts "Building a grouping Grid with GridView and ASP.NET AJAX toolkit CollapsiblePanel" & "GridView Grouping Master/Detail Drill Down using AJAX and jQuery" asking to for toggle all (Expand All or Collapse All) feature in CollapsiblePanelExtender as well as to in jQuery. Actually I didn't have much time to walkthrough this and provide a demo about it.

Today I got a chance to write few code snippet to run this feature. It was very simple for both jQuery also for ASP.NET AJAX.

I'll start with ASP.NET AJAX [View Demo]. If you wish to apply Toggle All functionality that will collapse or expand all panels on your page you can write code close to this and get it working perfectly:

function toggleAll(collapse) {
	var components = Sys.Application.getComponents()
	for (var i in components) {
		if (AjaxControlToolkit.CollapsiblePanelBehavior.isInstanceOfType(components[i])) {
				components[i].set_Collapsed(collapse);
		}
	}
}

At line 2 I am getting all component created on the page. In line 3 I am looping through all these components. In line 4 I am checking if these component are of Type CollapsiblePanelBehavior. If yes, in line 5 I'm expanding or collapsing each panel based on the passed parameter.

Very simple! but has one issue. What if you want to toggle group of panels on the page and leave the other panels! Then you need some kind of grouping. In my case I don't have this need, however I applied grouping by checking ID of the collapsible element for certain string pattern using regular expression

function toggleAll(collapse) {
    var components = Sys.Application.getComponents()
    for (var i in components) {
        var exp = new RegExp("pnlOrders");
        var match = exp.exec(components[i].get_element().id)
        if (AjaxControlToolkit.CollapsiblePanelBehavior.isInstanceOfType(components[i])) {
            if (match && match.length > 0) {
                components[i].set_Collapsed(collapse);
            }
        }
    }
}

In the above code I am checking if the collapsible element has id that contains "pnlOrders". This way If there are any other collapsible panel in the page that doesn't have a collapsible element that contains "pnlOrders" string in its id will apply this toggle feature. [View Demo]

In jQuery It was very simple too [View Demo], but required some customization in the code as my demo wasn't based on pre-built plug-in or widget on jQuery, it was purely customized jQuery code to apply sliding collapse & expand behaviour. Unlike ASP.NET AJAX where I already had a component of Type CollapsiblePanelBehavior.

My jQuery code was simple anyway:

function toggleAll(collapse) {
    $('.group').each(function(i) {
        var $this = $(this);
        var $details = $this.next();
        if ($details.html() == "") {
            if (!collapse) {
                $this.click();
            }
        }
        else {
            var src = $this.children()[0].src;
            if (collapse) {
                $details.slideUp();
                if (src.endsWith("minus.png"))
                    $this.children()[0].src = src.replace('minus.png', 'plus.png');
            }
            else {
                $details.slideDown();
                if (src.endsWith("plus.png"))
                    $this.children()[0].src = src.replace('plus.png', 'minus.png');
            }
        }
    })
}

At line 2 I get all elements with css class "group". This is equivalent to Expand/Collapse Control -The element that trigger expand or collapse on collapsible element- referenced here as $this. In line 5 I check if the element was expanded before or not by checking if it contains any HTML. If the collapsible element $details does not contain any HTML I check if I am triggering to expand all then I just call "click" function of the Expand/Collapse control to expand the collapsible element. If the element was already expanded before I just check if I am triggering expand all or collapse all and slideUp or slideDown the collapsible element. Also I manage to display the correct image on each case. [View Demo]

You can check out the demos and download the code for more clarification.

Book Review: Entity Framework Tutorial

mosessaur — Fri, 19 Dec 2008 18:14:50 PST

Information About the book:

Book Title: Entity Framework Tutorial
Book's Page: http://www.packtpub.com/entity-framework-tutorial/book
Book Cover:

Chapters: 8
Type: Tutorial
Publisher: PACKT Publishing
Author: Joydip Kanjilal

Introduction:

Since the release of .Net 3.5 SP1 & VS.NET 2008 SP1 which include Entity Framework v1 I started to play with EF and discover its usage and differences between it and LINQ to SQL.

Last month I got a change to have a book that walks through Entity Framework by tutorial. This book was Entity Framework Tutorial. The books itself is very small. It has a clear focus and scope; to put you on the road on how to build & use Entity Model of Entity Framework following comprehensive tutorials.

About Entity Framework Tutorial Book:

The book is small one, 228 pages on 8 Chapters. This books is targeting beginners who never used or even heard of Entity Framework. But of course the reader should be experienced developer with Microsoft .Net (general), ADO.NET & C#.

Entity Framework Tutorial at glance:

The book is divided into 8 chapters. 7 Chapters about Entity Framework and the last chapter is an introduction about ADO.NET Data Services.

Chapter 1 Introducing the ADO.NET Entity Framework. This chapter talks about What is EF?! and why it is not considered just another ORM. It also explains Entity Framework Architectural components. Finally in this chapter you'll setup the tutorial database that you are going to use across the book. This chapter is a must if you never heard or know what Entity Framework is about.

This book was written during Beta version of EF. So chapter 1 has a section that explains how to install Entity Framework.

Chapter 2 Getting Started. Pure tutorial step by step to build your first Entity Data Model. It will make you familiar with Entity Framework Designer and generation tools (EdmGen tool). The tutorial covers both, using Entity Framework Designer and using EdmGen tool to generate Entity Data Models. Finally you are going through another tutorial to build very simple ASP.NET Web Application that will consume the EDM created earlier. This tutorial will introduce EntityDataSource data control.

Chapter 3 is about Entities, Relationships and the Entity Data Model. You are going to understand Entity Types, Entity Sets & Relationships. It will also shows different types of Entity Inheritance. It will also show you different Designer Windows and how to interact with them. Finally it will take you through EDM layers (CSDL Conceptual Schema Definition Language, SSDL Storage Schema Definition Language & MSL Mapping Schema Language).

Chapter 4 Working Stored Procedure with Entity Data Model. Through Tutorial it will show you how to map create, update & delete functions in Entity Data Model to existing stored procedures in your database. Also it will show you how to map stored procedures that return custom entities to your EDM. During all this will walk through the issues that currently exists in current version of Entity Framework when mapping to stored procedures and shows you step by step how to resolve them.

Chapter 5 Working with Entity Client and Entity SQL. Introducing new Entity Client APIs with new T-SQL like language made specifically for Entity Framework, Entity SQL. This chapter talks about when you might wish to use Entity SQL over LINQ to Entities. It walks through the features of Entity Client APIs & Entity SQL to do different types of operations against your Data Model such as querying and paging through your data, executing commands, transaction management etc... Also It show different operators and functions available in Entity SQL.

Chapter 6 Working with LINQ to Entities. Assuming you know nothing about LINQ, this chapter gives you an introduction about LINQ in general and different flavours of LINQ. After this it will focus on the main subject about LINQ to Entities and how to do queries against your EDM using LINQ to Entities. This chapter also talks about the differences between LINQ to SQL and LINQ to Entities.

Chapter 7 Working with Object Services Layer. It is time to talk about Object Services in EF and its features. This chapter walks through different subjects such as add, modifying and deleting objects using object services APIs. Attaching & detaching objects from and to contexts. Change Tracking of objects and serialization and deserialization operations on entity objects. This chapter will show you the importance and powerful of Object Services.

Chapter 8 Introducing ADO.NET Data Services. An introductory chapter about Data Services and its usage showing the difference between Data Services and normal Web Services. Exploring System.Services.Data namespace. And walk through how to expose your EDM to Data Services and consume this service by querying it, insert, update and delete using your data service through Data Services Client Library.

Personal Opinion:

This book a good tutorial and starting point to Entity Framework. Especially for those who want a crash start in short time. This book never talks about limitations of Entity Framework so never expect that it will show what you cannot do with Entity Framework or the issues currently exists in current version except for those mentioned in chapter 4 about mapping to stored procedures.

The book is based on Beta Version of Entity Framework. At the time of writing this review the source code of the tutorial wasn't updated by the publisher, so you'll take some time to make it work on .NET 3.5 SP1 RTM and VS.NET 2008 SP1 RTM.

The book has few mistakes so you need to be careful will reading or applying code snippet mentioned in the book.

May rate for this book is 3.5 out of 5.

Conclusion:

This is a tutorial book and not a developer reference guide. It will take you step by step to build your Entity Data Model with Entity Framework. This book fulfil its mission as complete tutorial & how to guide. Suitable for beginner developers who are experienced with ADO.NET & C# 2.0.

Going live with Egyptian Yonklies Network though Yonkly.com

mosessaur — Thu, 04 Dec 2008 22:10:21 PST

I received an invitation to create first Egyptian Twitter like community on Yonkly.com. Thanks to Emad Ibrahim Creator and Founder of Yonkly.

Before I go further; you might ask What is Yonkly? My answer is: it is an enhanced twitter like mini blogging service. It is an open source project based on ASP.NET MVC. It is one of the first projects developed with early preview releases of ASP.NET MVC. This project was developed by Emad Ibrahim.

More information about Yonkly can be found at http://www.emadibrahim.com/category/yonkly/. You can download bits of this project from CodePlex.

2 different flavours of Yonkly are available through Yonkly.com, and Yonkly.net. The public Twitter clone is available at Yonkly.net, this is exactly like twitter with additional features like Groups. The other flavour which I am going to call community like edition is available under Yonkly.com. At Yonkly.com you can create your own community like Egyptian Yonklies I just created for Egyptian Tweeters. Both are in Beta as ASP.NET MVC itself is beta. Currently it require an invitation to be able to create your own network under Yonkly.com.

I think what is available on Yonkly.net should be available for each network under Yonkly.com. But this is something Emad should decide.

Today I was exploring Yonkly features while I was setting up egyonklies.yonkly.com. I was amazed by the provided features which I am sure is going to be enhanced and improved upon the release of ASP.NET MVC and in the upcoming releases of Yonkly.

Yonkly provide a simple control panel for community administrators through this control panel an admin can edit settings, appearance, email templates and many other things.

I thought to give you a snap shot of the currently available settings on yonkly.

I liked that it provides a way to link to custom domain and changing home page. However Emad also talked on one of his posts about Widgets and Ads. Ads is provided out of the box but currently is not released on this beta version of community yonkly. But what about Widgets?! This is one of the cool features found on Yonkly.net! So far I couldn't find it under my community network. With widget each user should be able to add sidebar widgets that should appear on his page. If you visited http://yonkly.net/mosessaur you'll figure that out.

With yonkly you can brand your network with your own custom look and feel. Currently you can change you theme from one of available themes. You can also change your logo. But later you'll be able to do more customizations on the look and feel of your network.

That was Yonkly at a glance. I wish for this project to grow and grow. This project is one of the greatest learning resources about ASP.NET MVC. So don't forget to download it and explore its code.

At the end feel free to join Egyptian Yonklies network even if you are not Egyptian. It is new and hopefully will grow by its participants.