Today I went to a talk by Hadi Hariri about dynamics which was arranged for the ANUG user group in cooperation with the goto conference. The talk happened to fit very well with the first topic I had planned for my series on Webmatrix Webpages, which is dataaccess.

The talk was about not fearing dynamics, and some of the scenarios where it can provide some benefits over static types. Some of the scenarios Hadi talked about were DTO’s, ViewObjects and for DataAccess, which is exactly what WebMatrix WebPages utilizes.

The flood of Micro-ORMs

Over the last year or so a lot of so called Micro-ORMs have seen the light or day with some of the more popular ones being Simple Data, Dapper, PetaPoco and Massive. The reason for their popularity is that they provide a sense of simplicity in the vietnam of computer science as Ted Neward put it.

Each of these ORMs have their own focus, strengths and weaknesses – and some are more “Micro” than others. Compared to NHibernate or Entity Framework they are all very simple to get started with. For quite a few of them part of the strength is the return of good old SQL in stead of LINQ or some other abstraction.

WebMatrix.Data

When a new Webmatrix Webpages project is created it comes with its own Micro ORM out of the box. The ORM allows queries and commands to be executed, which are expressed as SQL statements. For queries data is returned as dynamic objects. So a regular query could be done like this.

var db = Database.Open("myDatabase");
dynamic user = db.QuerySingle("SELECT * FROM Users WHERE User_Id = @0", 123);

The big advantage of this approach is that you can select any fields, calculate fields, join with other tabels to your hearts content and you won’t have to write a class to represent each shape of the data returned. This also means that we can use the power of SQL and that we avoid overcomplicating things.  Because the distance from database, to query and then to the view is so short working with dynamic objects is not a problem. So if your domain is not too vast and complex life is good.

Doing inserts and updates is equally easy, but it is one of the areas where I find the ORM lacking. Most annoying is that it does not handle converting null to DBNull. Also while you do get extention methods to convert strings as int, DateTime etc, there is no option to get null instead of the default value of the datatype. So the code tends to get cluttered with parsing and conversions – if you don’t write the extentions yourself.

Clean Ajax

A nice surprise for me was how easy it is to expose data as JSon to enable Ajax when working with WebPages. All you have to do is create a WebPage that retrieves data, pass it to JsonEncode and write it to the response like this example shows.

var json = Json.Encode(user);
Response.Write(json);

Life does not get more simple than this, and it leaves you with this smooth feeling when moving data between server and client.

Conclusion

The dataaccess bits for WebMatrix have been fun to work with, and it has given me a great sense of freedom to get things done, without having to do viewobjects, mappers and a bunch of configuration.

The fluidity of working with dynamic data, and doing ajax certainly has opened my eyes with reguards to the value that this kind of framework can provide. “The return of SQL” has also reminded me, that LINQ is not all rainbows and smiles. The power of micromanaging a JOIN statement and doing UPDATES and deletes should not be overlooked.

Using the right tool for the right job is still the key phrase though. It has been a good match for this project I am working on, but I would not want to use it for an enterprise application. Testability is clearly not a goal of the framework, refactoring is error prone and when complexity increases the code tends to get messy.  So if anything I will argue that it proves that the place for WebMatrix is hobbyists, simple projects, startups and prototyping.

The last thing I will compare in this round of Battle of the ORM’s is how NHibernate and the Entity Framework handle persistence. So first of all I want to vent one of my pet peeves, which is the myth of persistence ignorence.

Persistence ignorence is a term used to describe a persistence mecanism that does not contaminate the domain model and hence the business logic. This means that the model can be ignorent of how it is stored and not contain detals about the datastore. I think this a very important design goal to strive for, however actually obtaining true ignorence is a myth and something no ORM is even close to achieving.

In the previous Battle of the ORM's post I looked at setting up and configuring NHibernate and Entity Framework. So the next step is to get down to business and look at querying - the most important part of an ORM.

Gimme gimme gimme

First I need to address that the Entity Framework CTP5 has been released. This means that some more features have been added, which you can read about on Scott Guthries blog. Besides that there are some classes that have been renamed, which actually makes my last post mildly obsolete already. The renaming means that the Database class now is called DbDatabase – apparently redundancy is the new black – and that the databaseinitializer classes are called CreateDatabaseIfNotExists, DropCreateDatabaseAlways and DropCreateDatabaseIfModelChanges.

These days most developers use LINQ, myself included, but a very common issue is that not all LINQ implementations are created equal. Actually the reason I started this whole comparison project, was because I have been using an NHibernate 2.x, where LINQ to NHibernate was a seperate project - and suffice to say I have had my share of fights with it. Now it has been "baked in", and it has taken a pretty big leap forward.

Following up on my last post and on reading NHibernate 3.0 Cookbook I decided to download the latest NHibernate bits (v. 3 CR1), and do a comparison to Microsofts Entity Framework.
NHibernate and Entity Framework are what most developers reguard as the top Object Relational Mappers out there. So looking at how they stack up is pretty important in order to be able to choose the right ORM for a given project.

A few weeks ago we got a copy of the NHibernate 3.0 Cookbook by Jason Dentler, which I was really looking forward to because of the scattered nature the existing documentation for NHibernate.

The word Cookbook really says a lot of how the book is structured, and how it should be used. The book consists of a bunch of recipes on how to cook with NHibernate – terrible wordplay, I know, and I am sorry :) So basically it can be a good idea with a quick readthrough, and then it will serve as a place to look up solutions to various scenarios you will be dealing with when using NHibernate.

If you are new to NHibernate you will of course also gain an overview of the different topics you need to know about and as an experienced user you might stumble upon some features you didn’t know about.

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...

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.

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

Nye frameworks, tools og principper

Starten på det nye år, som samtig har været starten på nyt job for mig, har betydet at det var tid til at lære nogle frameworks at kende som jeg ikke tidligere har brugt professionelt. Det har været rigtigt spændende, men har også fået mit hoved til at eksplodere i forhold til tanken om at skulle blogge om det. Jeg vil derfor skrive lidt om hvad jeg har set på, fordi det nok er en del af de ting bloggen kommer til at omhandle fremadrettet.

Vi er en shop der gør alvor af at arbejde efter agile pricipper så jeg har haft tid til at kigge på ORM, Unit testing, mocking, Dependency Injection, Continuous Integration og Migrations. Dertil kommer Office Interop og ASP.NET MVC, som jeg endelig får mulighed for at bruge professionelt, hvor det ellers har været på todo-listen hjemme siden jeg fik leget med de helt tidlige bits. Og sidste men ikke mindst har jeg kigget op tools til synkronisering og deling af data.

Object relationel mappers

Mere præcist har jeg i forbindelse med ORM's kigget på NHibernate, Fluent NHibernate og LINQ to NHibernate, samtidig med at jeg har en bog på vej om LINQ to entities. Jeg håber LINQ to Entities udvikler sig til et reelt alternativ til NHibernate, som jeg lige knap synes det er idag. Hovedanklagen idag er at det ikke giver persistence ignorence, hvilket er et stort minus i forhold til at få et pænt løst koblet design. Det er dog et issue Microsoft er klar over, og noget de arbejder på til vNext. Et andet issue der arbejdes på som er væsentligt er iøvrigt model drevet design, hvor LINQ to Entities idag er meget datadriven.

Continuous Integration

Opsætning af et continuous integration miljø, som skal baseres på Team Foundation Server er en anden ting jeg er ved at se på. Umiddelbart virker det nemt at komme igang med, men udarbejdning af build scrips skal nok blive interessant at se på. En overvejelse er blandt andet om man skal holde sig til at bruge MS Build Server eller om NAnt viser sig at være den rigtige vej at gå?

Migrations

Migrator.NET har været rimeligt nemt at komme igang med, bortset fra at dokumentationen er rimeligt tynd, så selve konfigurationen skulle det lige pilles lidt ved for at få det til at spille.

Data synkronisering og deling af data

Idet jeg er begyndt at pendle er synkronisering af data imellem min desk- og laptop også blevet et super relevant emne, hvilket fik mig til at afprøve synctoy, live sync, mesh, skydrive samt servicen delicious. Mesh har jeg forelsket mig lidt i, selvom jeg må erkende at stabiliteten ikke er god nok endnu i beta versionen, samtidig med at de 5 GB plads man får idag er lidt tyndt når man på et skydrive får 25 GB.