DotNetNerd's blog

This week I ran into a problem when we were deploying a webapplication that uses ajax-enabled webservices to an environment that uses loadbalancing. The services were running fine in the stage environment and when each of the servers were called directly, but as soon as we went through the loadbalancer they failed.

I started by checking if the svc files could be reached, and surely enough they could be accessed from the servers, but through the loadbalanced domain I got a 404.

Reading blogposts on the subject provided little help – well actually it just hightened my degree of confusion. So after some time I started thinking about IIS bindings. I remembered that I had written a custom WebScriptServiceHostFactory because we had several bindings which IIS doesn’t handle too well.

using System;
using System.Configuration;
using System.ServiceModel;
using System.ServiceModel.Activation;

namespace MySite.ScriptingService
{
    public class MyCustomHostFactory : WebScriptServiceHostFactory
    {
        protected override ServiceHost CreateServiceHost(Type serviceType, Uri[] baseAddresses)
        {
            //This makes it possible to control which binding is used by sorting them in IIS.
            return new ServiceHost(serviceType, baseAddresses[int.Parse(ConfigurationManager.AppSettings["BindingIndex"] ?? "0")]);
        }
    }
}

I started playing around with which binding we used, and as I suspected if the binding was not the one for the loadbalanced domain it returned the 404. This was one of those “doh!” moments. I still had a problem though, because the site could be accessed both with and without the www subdomain. A colleague pointed to the fact that we could use the URL rewrite plugin for IIS, and have it ensure all traffic was directed through one of the domains. As it turnes out it actually has a CanonicalHostNameRule that does just this because its a SEO good practice. Only issue I had left was that umbraco on the other hand has a practice that it must be accessed directly on one server, so changes are made on the master and replicated to the slave(s). This just required extending the conditions so it does not redirect if the umbraco folder is part of the path.

So now by posting this I hope Ill save someone else from getting a few extra gray hairs, and if not maybe I’ll save my self some other time when I can’t remember how I did…

Since my last post Rob Connery has joined the team working on MongoDB, and he recently blogged about the latest additions he has made on github. I couldn’t resist taking a look at the latest changes, and even though there is still some way to go it is nice to see the improvements to the drivers for .NET.

My last sample is already depricated, so Ill shamelessly steal his sample, and modify it slightly just to see the new bits running with entities that I worked with last. So Ill recommend looking at the sample from the blogpost, since I’ll be using his session class.

First thing to notice from Robs sample is that I don’t have to think much about mapping classes to documents any longer. One thing that is already depricated even from Robs own sample is that it is now a requitement that the class has an identifier. So going with the simplest thing possible I added an ID integer.

using (var session=new Session()){
   session.Add(new Actor { ID = 1, Name = "Hans", Age = 40, Gender = Gender.Male });
   session.Add(new Actor { ID = 2, Name = "Eva", Age = 22, Gender = Gender.Female });
}

So comparing to Db4o, we are now closer to a similar experience. One of the things I’ll wait to look at, but I see as fairly importait is how either will handle Lazy<T> properties and other kinds of more advanced scenarios.

With the above objects saved the data can be accessed using a Linq query like so:

using (var session=new Session())
{
   var actors = session.Actors;
   foreach (var actor in actors.Where(a => a.Gender == Gender.Male))
   {
       Console.Write(actor.Name);
   }
}

The LINQ provider is still not too far along so I’ll leave it alone for now, but it is also one of the places where it will be interesting to compare e.g. db4o and MongoDB in the future.

Ayende, who most know to be one of the Guru's when talking about ORM's and by extention working with relationel databases came to a very interesting conclusion a couple of days ago when he received a phonecall. To parafrase his point in "Slaying relational dragons" in a few words, a very real and complex problem had one very simple and elegant solution - do not use a relational database. This acknowledgement is as a see it a strong incentive to take a look at what NOSQL solutions like document and object based databases has to offer. And his blogpost is something I would definitely recomment reading...

As the next step in my recent adventures into NoSQL country I decided to take a look at db4o. Shortly put I hope it will give me more than the document based databases, like Mongo that I have also been taking out for a spin.

My interest in NoSQL has been kindled further than it already was because of blog posts from Rob Connery, who looked into practical approaches and posts on CodeBetter provokingly entitled Using an ORM is like kissing your sister. Basically what they are all saying is that it is very limiting that we always start out with a relational database without even considering this very very important architectural decision.

Object vs Document

Similar to the document based database, the big win is that there is no schema, and no need to map between objects and a relational model. Actually with document based databases you do map to key/value pairs, so it’s not the whole truth, but still simpler than mapping to a relational model.

Mapping can be expensive in two ways – because it takes time to write the code, and it does warrant a certain overhead. On top of that db4o as an object oriented database has a concept of relations between objects. This means that rich querying capabilities are build in and that it performs really well.

When comparing to MongoDB the big thing missing is that it basically works on a flat file out of the box. So you need something to handle concurrency and stuff like that. Rob Connery posted a nice sample of how this could be done, and its really quite straight forward, because db4o does provide all you need to do it.

The basic stuff

In the interest of simplicity I’ll just sample how to work with db4o directly. Also this will illustrate just how straight forward it really is. The first thing that brought a smile to my face was how little I had to do to save and query a bunch of objects.

using (IObjectContainer context = Db4oEmbedded.OpenFile(Server.MapPath("myDatabase.yap")))
{
    var empolyeeToSave = new Employee() { Name = "John", Card = new TaxCard() { Number = "12345678" } };
    context.Store(empolyeeToSave);

    IList<Employee> retrievedEmployees =
        context.Query<Employee>(employee => employee.Card.Number == "12345678");
}

As you can see it’s very straightforward stuff. Besides this type fo querying which takes a predicate, there is also a QueryByExample, which works as one would expect. Another nice thing is that all calls to the Store method make up a transaction, so there is a Rollback method available. When the context is disposed the convention is that Commit is called for you, so when you don’t need rollbacks you don’t have to think about it.

Indexing is also possible with db4o, and it is also very simple to do, so if for instance I would like to apply an index for the name property on my Employee I could do this.

Db4oFactory.Configure().ObjectClass(typeof(Employee)).ObjectField("Name").Indexed(true);

Moving along

Some of the first things that I have heard people think about when I say object/document based database is how to handle versioning and querying. With querying in this case I mean how to enable a scenario similar to opening SQL Manager and writing some queries to take a look at the actual data.

The versioning part may take a little work, but there are methods to help with e.g. renaming directly baked in - and besides, it takes work no matter what kind of database your using. On top of that my thought is that both of these issues can be addressed with a dynamic language. My plan is to take a look at this at some point, and that it will fit nicely because my copy of IronRuby Unleashed should be on it’s way :)

Even though I have been pretty disconnected during the holydays I couldn’t help read that Rob Conery wrote quite a bit on his blog about his thoughts on Ayendes “EF vs NHibernate” discussion. Rob Conery argues that he is tired of these discussions and that we need to look at the NOSQL movement and instead focus on alternatives to relational databases.

I found this pretty interesting and decided that it was finally time for me to take a look at one of the document based databases out there. As Rob mentioned MongoDB I thought this was a good a place to start as any. Based on my experiences I then decided to do this post on what I learned about getting MongoDB up and running. So first of all, the steps to get a MongoDB server running are:

1. Download and unpack from: http://www.mongodb.org/display/DOCS/Downloads
2. Create folder C:\data\db and make sure the server has read and write access
3. Run the server from cmd. Go to dir where you unpacked (eg: "c:\MongoDB\bin") and run "mongod"

You can now work with the database from the commandline, but to start writing some code you need to get a driver that suits you. In my case I went with a driver so I can write my code in C#. This driver along with a early edition of a LINQ library can be downloaded from http://github.com/samus/mongodb-csharp/downloads 

This is all you need to get going, so just create a new project and start coding!

A good sample can be found here http://blog.dynamicprogrammer.com/2009/11/10/UsingMongoDBFromC.aspx and if your into F# this might be interesting http://gist.github.com/218388

The first sample focuses on two ways to handle converting objects into documents.

1. Serialize object(hierarchy) into JSon using JSonConverter - which was the sample I focused on.
2. Make entities implement the IMongoEntity interface – which basically just makes your entity expose a Document property which then contains the state for the entity.

Of course I wont cheat you from seeing the bit of code I started out with, which is heavily inspired by the before mentioned blog posts.

//Connect to the database
var mongo = new Mongo();
mongo.Connect();
var db = mongo.getDB("movieReviews");

//Access the collection that you wish to work with
var movies = db.GetCollection("movies");

//Add a document
var movie = new Document();
movie["title"] = "Star Wars";
movie["leadActor"] = JsonConvert.SerializeObject(
 new Actor() {Name = "Mark Hamill", Age = 26, Gender = Gender.Male});
movie["releaseDate"] = new DateTime(1977, 5, 25);
movies.Insert(movie);

//Do a query
var result = from mov in movies.AsQueryable()
             where (string)mov["title"] == "Star Wars"
             select mov;

//Write out info from document
foreach (var document in result)
 foreach (string key in document.Keys) Console.WriteLine(document[key]);

//Deserialize and write name
Console.WriteLine(JsonConvert.DeserializeObject<Actor>((string)result.First()["leadActor"]).Name);

//Disconnect from database
mongo.Disconnect();

You'll also need this simple class for the sample:

public class Actor
{
 public string Name { get; set; }
 public int Age { get; set; }
 public Gender Gender { get; set; }
}

public enum Gender
{
 None = 0,
 Male = 1,
 Female = 2
}

Linq implementationer rettet imod databaser har gjort der nemt tilgængeligt at anvende lazy loading og at opbygge querys via komposition. “With great power comes great responsibility” fristes jeg til at skrive, da den meget integrerede brug af lazy loading gør at man skal huske selv at overveje hvornår querys skal omsættes til SQL og afvikles imod databasen. Det har udviklet sig til et best practice råd i MVChvor det direkte bryder med MVC mønstret idet man flytter logik til viewet – hvilket naturligvis kan være et lige så stort problem i andre framework.

I forlængelse af diskussionen omkring hvornår querys afvikles giver Linq anledning til at overveje hvordan man vil indkapsle sine querys? Den før omtalte Repository is dead: Long live repositoryblogpost omhandler netop diskussionen om man skal have en metode pr query eller om selve filtreringen er et argument der passes til metoder som T FindOne(Expression<Func<T, bool>> expression). Kort og sagt med andre ord er argumenterne for hver indkapsling vs Open Close Principle.

Indkapsling og dermed også genbrug af querys anser jeg ihvertflad som vigtigt, men der er andre måder at gøre det på end ved at lave et repository med “en metode pr. query”. Den første tanke er tit at man kan lave en service ovenpå sine repositories som indeholder querylogikken. Det vil imidlertid betyde at en sådan service blot bliver et gennemstillingslag for simple querys – og det er kode jeg ikke kender nogen der synes er sjovt at skrive.

Filtre som extention methods en elegant måde at skrive querys der kan genanvendes og skabes via komposition ved hjælp af piping f,eks new Repository<Customer>().FindAll().WithAddress(adr).WithNumberOfChildren(2); Som altid er der imidlertid “no such thing as a free dinner”, da det ikke sikrer at querys bliver afviklet. Her er min konklusion indtil videre at jeg vil vise tilbage til den tidligere nævnte best practice, og lade det være udviklerens ansvar.

Object-Relational Mappers eller bare ORM’s er værktøjer der håndterer det at mappe imellem relationelle data i en database til objekter som vi gerne vil arbejde med dem (og tilbage igen naturligvis). Der findes efter hånden et hav af forskellige ORM eller ORM-lignendene værøtøjer hvor nogen af de mest udbredte er SubSonic, LightSpeed, NHibernate, LINQ to SQL og LINQ to Entities.

Personligt er det de 3 sidstnævnte jeg hovedsageligt har erfaring med, og hvor NHibernate er det jeg primært anvender idag. Der er mange ting at vurdere når man vælger et ORM, men det der normalt afgør ens valg er kompatibilitet med andre teknologier, hvor “tungt” frameworket er og hvor fleksibelt det er. Med fleksibilitet menes her normalt hvordan man kan beskrive sine mapninger og hvilke typer mapninger der er mulige. Det er eksempelvis ikke alle der understøtter mange-til-mange relationer.

Som helt kort guideline vil jeg idag anbefale NHibernate hvis man skal have mest mulig fleksibilitet, LINQ to Entities hvis man vil have best mulig kompatibilitet med .NET teknoligier (især kommende teknologier) og en af de sidst hvis man gerne vil have et mere letvægts ORM der er let at gå til.

Jeg skal muligvis passe på med at kalde LINQ to SQL/Entities for ORM’s, da især Microsoft argumenterer for at de er noget lidt andet. De fleste anser dem dog som ORM’s, og jeg vil også argumentere for at det er hvad produktet er “at it’s core”.

En anden udbredt misforståelse er at LINQ i sig selv er en database teknologi og har noget med et ORM at gøre. Det er imidlertid forkert, da LINQ udelukkende som navnet (Language INtegrated Query) antyder er et sprog til at skrive querys imod en eller anden for for datastore. LINQ providerne til SQL/Entities udgør imidlertid hvad jeg vil kalde ORM’s, da de netop håndterer mapning og persistering af data i databaser.

Der findes en version af LINQ to NHibernate, som efter min mening giver den bedste blanding af et gennemprøvet og fleksibelt modelleringsværktøj i NHibernate, sammen med et lækkert query sprog i LINQ. Til komplekse querys har det imidlertid stadig nogle fejl og mangler, så træerne vokser ikke ligefrem ind i himlen.

En af de ting der bliver talt en del om idag, og som især LINQ to SQL/Entities bliver kritiseret for ikke at give er en Persistence Ignorent domænemodel.

“Persistence ignorance (PI) is a property of "ordinary classes where you focus on the business problem at hand without adding stuff for infrastructure-related reasons.”

Det vil sige om man skal skrive kode i selve modellen der beskriver hvordan objekterne mappes, og om valget af ORM stiller nogen krav til ens øvrige kode.

PI er især et fokusområde for agile udviklere, og det er heldigvis et område Microsoft har fået øjnene op for, således at de har arbejdet på at opnå PI med LINQ to Entities i v2. Lige som afsluttende bemærkning kan jeg nævne at successen med at implementere det nok kommer til at afgøre mit valg af ORM fremover.

I Eric Evans bibel om Domain Driven Design skriver han "any object internal to an aggregate is prohibited from access except by traversal from the root". Det vil altså sige at man skal have et repository pr aggregate root, og at interne objekter kun må tilgås via navigation for at sikre indkapsling. Derudover må externe objekter kun må holde referencer til rooten og transient references til value objekter.

Kunsten ved at designe sine repositories på den måde er at få defineret sine aggregate roots rigtigt. Laver man et design hvor man anser en klasse som værende en del af en aggregate, og man senere erfarer at der skal kunne søges på properties på objektet og vises lister af dem, vil det kræve en refaktorering, da denne nu må være root.

Nogen typer systemer er karaktaristiske ved at næsten alle klasser kan ses som lister og er søgbare - i den typer systemer vil repository designet begynde at ligne en en-til-en mapning med de tabeller man har i databasen. Man kan imidlertid argumentere for at så længe det forhold opstår af den årsag er det ikke symptom på at designet er databasedrevet, men blot den naturlige måde at designe systemet på. Service orienterede løsninger vil som eksempel i mange tilfælde fungere naturligt på den måde.

Personligt kan jeg godt lide DDD måden at tænke repositories på, da det sikrer indkapsling og lægger op til at persistence ignorence ved at man undgår at repositories blot afspejler databasestrukturen. Dog vil jeg understrege ordet principper - da disse ofte er til for at blive brudt.

Jeg er jævnligt løbet på systemer hvor granuleringen af klasser og metoder bliver unaturligt hvis man følger fremgangen slavisk. Her kan det eksempelvis være en mulighed at lade repositories have metoder til at søge efter objekter der er interne i en aggregate - selvom det bryder direkte med ovennævnte principper.

Andre gange kan det virke helt naturligt at anskue dataaccess som mapning af tabeller - både fordi den teknologi man anvender til dataaccess låner sig bedre til det, og i systemer der af natur er meget datadrevne. RAD og udvikling af prototyper kan også i sig selv som princip være en modsætning, da det at designe repositories omkring aggregates kræver mere designmæssigt omhu.

Repositories er omdrejningspunktet i de fleste webapplikationer, og et godt repository design er derfor vigtigt. Jeg tror de fleste har prøvet at fortryde et designvalg i forhold til repositories og tænkt “why didn’t I take the blue pill”.

Da jeg startede som udvikler lærte jeg, ligesom så mange andre, at bygge et dataaccess lag hvor man typisk havde en klasse der håndterede adgang til en enkelt tabel i databasen. Det betød at database designet leakede ud i hele applikationen som blev databasedrevet. Sidenhen er ORM’s og DDD blevet mere udbredt og PI (Persistence Ignorance) tilstrebes. Samtidig er LINQ blevet den foretrukne måde at udtrykke querys på, hvilket giver en række nye design muligheder/beslutninger.

Derudover er der forskellige “skoler” med hensyn til om man mener querys bør indkapsles i et repository, eller om de skal ses som en del af ens business logic, og måske ligefrem være fuldgyldige objekter. Transaktioner og validering har desuden stor indflydelse på hvordan det kan være hensigtsmæssigt at designe sit repository - og hvordan det samlede design har indvirkning på hvordan applikationen struktureres.

For nylig læste jeg så en række blogposts der kan findes via CodeBetter’s “Reposptiry is dead: Long live repository”, hvor der netop blev diskuteret repository design, hvilket fik mig til også at tænke en ekstra gang over designet i mit nuværende projekt. Med udgangspunkt i de ting vil jeg derfor skrive en lille serie posts om emnet, hvor jeg i vilkårlig rækkefølge vil se på emner som:

• DDD principper
• Object-Relational Mappers
• Repositories som singletons
• Querying: fleksibilitet og indkapsling

Et sted jeg ofte oplever friktion imellem practices og frameworks er imellem godt objektorienteret design og webudviklings frameworks. Veldesignede objekter er sjældent specielt velegnede til f.eks databinding og serialisering. Eksempelvis kaster serialiseringsprocessen i MVC frameworket en exception, hvis man forsøger at serialisere et objekt der er del af en mange til mange relation (hvor to klasser har collections indeholdende instancer af hinandens typer). Det giver fint mening at det forholder sig sådan i en serialiseringskontekst, men omvendt kan man ikke i sit design undvære mange-til-mange relationer. I forhold til databinding kan det være et issue at man gerne vil databinde et objekt hvor nogle properties er komplekse typer, hvorfra der skal noget logik til at afgøre hvilken værdi der skal representere objektet i brugerfladen.

Løsningen på den slags udfordringer er ofte at lave en ViewData klasse der som udgangspunkt er et subset af den oprindelige klasse. Properties som er mere komplekse kan så fjernes eller ændres, og udregnede eller relaterede data kan tilføjes viewet. Som bekendt er der ingen designbeslutninger uden konsekvenser, og her er den tydelige konsekvens at man nu skal skrive kode til at mappe imellem entiteter og viewdata. I mange tilfælde er det virkelig trivielt, da properties navngives ens, så for at undgå at skulle gøre dette manuelt skrev jeg en MapToView metode.

public static ViewType MapToView<EntityType, ViewType>(EntityType entity) where ViewType : new()
{
    var view = new ViewType();

    var entityType = entity.GetType();
    var viewType = view.GetType();

    foreach(var property in entityType.GetProperties())
    {
        var viewProp = viewType.GetProperty(property.Name);
        if(viewProp != null && viewProp.PropertyType == property.PropertyType)
        {
            viewProp.SetValue(view, property.GetValue(entity, null), null);
        }
    }

    return view;
}

Den er naturligvis reflection baseret, og så siger ens barnelærdom jo at man skal passe på hvad det betyder for performance. En helt kort test hvor jeg har to klasser med 10 string properties som jeg mapper 1000 gange viste over 5 observationer at det tager ca. 53 gange så lang tid med MapToView frem for med manuel mapning. Det skal dog ses i det lys at vi snakker omkring 145 millisekunder på en 3,2 GHz Pentium 4 for de 1000 mapninger - så med mindre der virkelig er skarpe designkrav omkring performance vil det næppe være et issue.