Tuesday, 22 January 2008

With Genome, you can map standard 1:n and n:m collections for foreign-key/association table database patterns out of the box by using Collection<T> and <OneToManyCollection/> or <ManyToManyCollection/>.

Compared to arbitrary relationships, which can also be mapped with Genome by using Set<T> and a query, Collection<T> offers the following additional functionality:

  • Elements can be explicitly added and removed from the collection.
  • The collection is fully loaded into memory and kept consistent with in-memory object graph modifications.
  • For n:m collections, Genome can fully hide the association class (mapping the database association table) from the domain model if required.

However, for n:m collections, where the association class is annotated with additional values (besides the foreign keys), the standard Collection<T> mapping does not fit.

To provide better support for those mapping scenarios, I have created a Dictionary-like implementation for annotated many-to-many associations, where we can build the functionality on the existing collection support.


I will use a simple domain model to present the idea. Let’s say we have Departments and Employees in our domain. An employee can work in multiple departments, and a department can have more than one employee. This classic many-to-many association is annotated with a job description. The job description is encapsulated in a struct called Job.

So the logical view looks like this:

In the database, we represent this kind of association with an association class/table as follows:

The task is to implement the Department.Employees property, which represents the annotated n:m relation in a consistent way.

Representing an annotated n:m relationshop in the domain model

In my opinion the best representation for Department.Employees is an IDictionary<Employee, Job>. It is ideal because the employees must be unique within the collection, and the annotation data can be accessed if you additionally specify an Employee (index into the dictionary with that employee). Note that this representation is only possible if the annotation can be represented with a single typ; however, you can encapsulate the annotations with a struct or class to achieve this at any time. You can use the <EmbeddedStruct/> mapping feature to map this struct on the EmployedAs class.

Mapping the association table as a one-to-many collection

First we have to map the one-to-many collection (Department.EmployedAsCollection):

protected abstract Collection<EmployedAs> EmployedAsCollection { get; }

<Member name="EmployedAsCollection">
  <OneToManyCollection parentReference="Department"/>

Wrapping the association table into an annotated association

We will wrap this collection with a dictionary implementation to represent the annotated association. I have created a helper class AnnotatedManyToManyDictionary that carries out all necessary transformations. This strongly typed helper needs 4 generic parameters, as you have to specify the association class (TAssoc=EmployedAs), the class owning the collection (TOwner=Department), the “other side” of the association (that is, the key in the dictionary, TKey=Employee) and the annotation that is the value in the dictionary (TValue=Job). Basically, you have to wrap the collection with this helper:

public IDictionary<Employee, Job> Employees
    return new AnnotatedManyToManyDictionary<EmployedAs, Department, Employee, Job>
      (this, EmployedAsCollection, EmployedAsDepartmentEmployeeJobAccessor.Instance);

Helper strategy implementation for getting and setting the keys and values of an association item

The helper class manages the underlying one-to-many collection and the association items to provide the required behavior. As you probably noticed in the constructor call, it still needs a little bit of help. You have to pass a strategy that “knows” how to get and set the key and value properties of the association item. In the current example, the EmployedAsEmployeeJobAccessor strategy knows how to get and set the Employee and Job properties on an EmployedAs object. Currently you have to write this piece of code to make that work:

private class EmployedAsEmployeeJobAccessor : 
  IAnnotatedManyToManyDictionaryAssociationAccessor<EmployedAs, Employee, Job>
  public static readonly EmployedAsEmployeeJobAccessor Instance =
    new EmployedAsEmployeeJobAccessor();

  public Employee GetKey(EmployedAs assoc)
    return assoc.Employee;

  public void SetKey(EmployedAs assoc, Employee key)
    assoc.Employee = key;

  public Job GetValue(EmployedAs assoc)
    return assoc.Job;

  public void SetValue(EmployedAs assoc, Job value)
    assoc.Job = value;


Having done this, you can easily iterate through the employees in a department:

Department dep = GetSomeDepartment();
foreach(Employee e in dep.Employees.Key) { ... }

You can also iterate through the association elements to retrieve the associated employees of a department along with their job:

foreach(KeyValuePair<Employee,Job> in d1.Employees) { ... }

The job of an employee now depends on the associated department. The indexer of the employees collection takes an associated employee and looks up the job annotated to association:

Employee emp = GetSomeEmployee();
Job assignedJob = dep.Employees[emp];

Similarly, the job of an employee can be set for a specific department association:

dep.Employees[emp] = assignedJob;

Finally, when associating an employee to a department, the job annotation has to be specified as well:

dep.Employees.Add(emp, assignedJob);
Removing just requires the key, without the annotation:


The first limitation is performance with larger collections.. The current implementation uses a linear search for looking up the employee key in the collection, which can cause a performance hit in larger collections when adding or removing items or getting an item’s annotation (using the indexer). The reason for this is that I didn’t want to replace Genome’s internal representation of 1:n collections with a dictionary implementation.

The second limitation is that you need to manually code the helper strategy for getting and setting the annotation value in the association items.

Based on your feedback, we might implement this as a native mapping feature in an upcoming Genome release, thus resolving both limitations described.

Sample code

Please find the source code for the example described above attached to this article.


Posted by TZ.

Tuesday, 22 January 2008 16:41:14 (W. Europe Standard Time, UTC+01:00)  #    Disclaimer  |  Comments [2]  | 
 Friday, 18 January 2008
The using statement can be a little bit dangerous at times ...
Friday, 18 January 2008 22:31:47 (W. Europe Standard Time, UTC+01:00)  #    Disclaimer  |  Comments [0]  | 
 Wednesday, 09 January 2008
If you are using Visual Studio 2008 for a project, but are still using an old TFS and an old build server (which is quite likely at the moment), you should prepare for at least some inconveniences.
Wednesday, 09 January 2008 16:23:00 (W. Europe Standard Time, UTC+01:00)  #    Disclaimer  |  Comments [0]  | 
 Friday, 04 January 2008
Genome has been developed with Team Foundation Server (TFS) for some time now, and it might be interesting to know in this context that TechTalk is a Visual Studio Inner Circle partner. TFS has proven to be a good source control system, but there are a few points that could do with a bit of improvement (particularly when compared to Subversion (SVN), with which I have extensive experience; that said, there are some features that both systems lack).
Friday, 04 January 2008 16:19:22 (W. Europe Standard Time, UTC+01:00)  #    Disclaimer  |  Comments [0]  | 
 Thursday, 15 November 2007
As I am writing this, I am just heading home from TechEd, waiting at the Barcelona airport for my return flight to Vienna. It has been a busy time for the Genome team since September - unfortunately so busy that we couldn’t take time to blog about all the things that are going on. We weren't at TechEd only as attendees, but also exhibiting in the Visual Studio Partner area, with a total of 8 TechTalkers in Barcelona. To catch up with all the things that have happened since September, I’ll start with TechEd, while the memories are still fresh.
Thursday, 15 November 2007 20:02:27 (W. Europe Standard Time, UTC+01:00)  #    Disclaimer  |  Comments [0]  | 
 Thursday, 08 November 2007
Typically, Genome is used to map tables to their data domain objects. But what to do when you have to use a database that is not made for mapping objects and therefore is not in any normalization form etc.?
Thursday, 08 November 2007 16:23:06 (W. Europe Standard Time, UTC+01:00)  #    Disclaimer  |  Comments [0]  | 
 Tuesday, 18 September 2007

While documenting/testing Genome 3.3 I stumbled about this strange behaviour, which seems to be a bug of the C# 3.0 beta 2 compiler.

I was trying to compile the following GROUP BY example with Genome:

var ordersPerCountryPerYear1 = from o in Helper.DB.Extent()
                               group o by new { o.Customer.Address.Country, o.OrderDate.Value.Year } into g
                               select new
                                 Country = g.Key.Country,
                                 Year = g.Key.Year,
                                 OrderCount = g.Count()

And received the following error from the compiler:

error CS1061: 'System.Linq.IGrouping' does not contain a definition for 'Count' and no extension method 'Count' accepting a first argument of type 'System.Linq.IGrouping' could be found (are you missing a using directive or an assembly reference?)

However, my team insisted that the extension method Count() is provided by Genome. To find out, why the compiler does not find it, they asked me to call it directly in Main():


After inserting this call in my code, the program suddenly compiled (including the statement, the C# compiler complained about previously).

We think this is a bug of the compiler. As a workaround I now have the following method on one class in my project to satisfy the compiler :-) :

static void ThisIsNeverCalled()

Posted by Chris

Technorati Tags:

Tuesday, 18 September 2007 16:24:01 (W. Europe Standard Time, UTC+01:00)  #    Disclaimer  |  Comments [5]  | 
 Sunday, 16 September 2007

There are a lot of discussions how to properly mock an O/RM to achieve unit testing.

In this article, I will describe how an application implemented with Genome can be tested by means of unit testing. By stealing (and also modifying) the sample domain from Fowler, I’ll demonstrate this with a simple WebShop application. The use case that we are going to investigate is the ordering process itself.

The sample code used is provided for download at the end of the article. You need Genome 3.3 (beta 1) to execute the sample.

Sunday, 16 September 2007 14:25:25 (W. Europe Standard Time, UTC+01:00)  #    Disclaimer  |  Comments [0]  | 
 Saturday, 15 September 2007
TheServerSide.Net has just published our case study about DataReturn's experiences of using Genome to rebuild website for BMW USA. The site has quite critical performance requiremens of up to 1 million sessions per day.

Posted by Chris

Technorati Tags:

Saturday, 15 September 2007 09:19:10 (W. Europe Standard Time, UTC+01:00)  #    Disclaimer  |  Comments [0]  | 
 Tuesday, 10 July 2007

Recently we received a question from a customer about how to express a sort criteria based on a condition. As the sort expression in Genome is nothing else than an implicit function (lambda) executed on the candidate element to return the value to sort by, this can be quite easily achieved.

As a simple example, let’s use the Northwind database again. A customer there has a Country and a Region property. Imagine you want to order all customers in the USA by Region and all the other customers by Country. Additionally you want to have USA customers first, then the others.

A Genome set can be sorted using the OrderBy() method. It takes an implicit function as a parameter, which is denoted using [] in OQL. The condition can be expressed using the ? operator, which is translated to a CASE WHEN in SQL. Hence, the order function can be expressed like this:

When the customer is located in the USA, then order by region; otherwise, order by country:

Country=="USA" ? Region : Country

To make sure customers located in the USA are listed first, I am prefixing the Region with a space (I know this is a hack, but it will do for this example). Hence, the final OQL looks like this:

extentof(Customer).OrderBy( [ Country == "USA" ? " " + Region : Country])

which translates to the following SQL:

SELECT … FROM Customers
    CASE WHEN (Country="USA")
       THEN (" " + Region)
       ELSE (Country)

Posted by Chris

Technorati Tags: ,

Genome | OQL
Tuesday, 10 July 2007 20:00:41 (W. Europe Standard Time, UTC+01:00)  #    Disclaimer  |  Comments [0]  |