Battle of the ORMs
Today I spent the day sitting through 5 talks in Microsoft Reading (whoop whoop!) on ORMs each with their own benefits and downsides.
During the different talks I made a few squiggly notes which I’ve transcribed below with some post-mortem comments to explain what they meant:-
- ORM Framework – Andrew Cutforth
- Attribute decorated classes – All the classes that derived from the base class were adorned with numerous attributes to control behaviour of the classes which was interesting to me. Reflection was however a concern although this was managed using a meta data cache filled after the first “reflection” pass was run against object.
- WPF – none of the properties obviously supported INotifyPropertyChanged & certainly none implemented DependancyProperty for WPF bindings, validation & the like.
- 2 decimal places – the standard Currency data type restricted numerical values to 2 decimal places but I’ve experienced serious rounding issues at this low precision. 4 or 6 decimal places would be better for this although Andrew explained this could be easily changed.
- 19 warnings – I’m a strong believer in treating warnings as errors. Even though only a bunch of simple classes with almost no business logic were created it already generated 19 warnings! I’m sure they could be tidied up but it doesn’t fill you with confidence from the outset.
- Dodgy ID generation – One of the things that jumped out to me like a monster on a fairground ride was the way the framework generated new unique ids. It grabbed the biggest number from the table then incremented it once for each insert within 2 seconds. This had a certain code “smell” that I was not comfortable with, and would almost certainly give significant issues with a multi-user system. I’ve seen systems where a select statement followed immediately by an update on a single row “unique number” table overlapped when the timing is just right (or wrong?) causing dupe numbers to be generated; this implementation would be a minefield for these sorts of issues.
- Funky SQL – As with all ORM tools the focus is on improving the design time experience and abstracting the storage away; often at the detriment of the SQL (or equivalent) being run. Some of the SQL popping out of this ORM was nasty in places but this could probably be “adjusted” with intimate knowledge of it’s inner workings.
- Entity Framework – Eric Nelson
- What is it? – After an hour of demonstration I still felt like I’d no idea what Entity Framework would do for me, and how my code might be transported to it.
- Negative presentation – The other thing I noted about this presentation was how negative Eric was being about the Entity Framework. It was apparent that the product wasn’t as well rounded and I am sure this will come with v2 or v3. Strangely I spent more time wondering what LightSpeed was doing in this space after Eric specifically “sold” it to the audience.
- Intact Evolution Framework – Joanna Carter
- Visitor pattern? – One of the things I noticed about this talk was that there was a lot of jargon, lots of “in-jokes” about technologies, and lots of n-letter acronyms/patterns I wasn’t familiar with. I felt less inclined to raise my hand in this session in fear of feeling “naive” in a room of more knowledgeable people.
- No data type restrictions on constructor – One of the neat things I liked about this framework was the “domain” types that you needed to create to implement your business objects; ie. AccountCode which implemented a String with a certain length. The thing I found interesting was the constructor (& overridden operators) accepted any length string even though the attributes defined a restriction. In my eyes that seemed odd but may have been an oversight.
- owner, args, context – The validation delegate signature accepted three parameters, an owner of the property that changed, some strongly typed args for the value that changed, and the context the owner existed in. This was a clever way to design around the lack of knowledge at the class level of their parent. In the case shown an Invoice.Line was the owner, but the parent Invoice was the context, and since the Line knew nothing of the Invoice this would’ve been otherwise tricky to address.
- WPF? – as per the ORM Framework…
- DynamicProperty – This idea rang a bell in my head about some almost identical code we have in our system to manage client implemented structural changes to the database. This was the first and only ORM to offer any form of rounded dynamic schema management.
- TypeConverter<SalesOrder> – Another neat design trick was the use of TypeConverter generic classes to implement some rudimentary searching – such as retrieving Product class instances by allowing the user to enter a product code string that represented it. Using a TypeConverter to invisibly convert to the relevant type, or present a list of matches seemed like another really inspired idea that I will probably need to dwell on for some time to come.
- SQL fragment ordering – My significant concern with this framework was the blasé approach to database agnosticism. In particular Joanna just threw a comment out about implementing a new RDBMS by overriding the SQL fragments in her data layer classes. It seemed like, although I may be wrong, no serious thought had been given to the different sequence of fragments or to unique capabilities offered/restrictions enforced by individual database platforms.
- Startup code – One final thing that I didn’t like was the significant amount of code required in the app startup just to plumb all the framework, brokers, etc. together. This probably needs tidying up with some helper classes else this would make for some nasty code repeats on each new project.
- DevExpress XPO – Gary Short
- Simple – One thing that struck me about this implementation of ORM was it would be extremely lightweight on time & knowledge required to create some pretty representative classes that would wrap real world scenarios.
- Good argument against designers – The DevExpress team seemed to grasp the fundamental basic requirement of an ORM well; persisting OO classes in a database backend & abstracting this process away from the developer. Visual Studio configurators or designers although powerful would suggest a level of complexity not required to achieve the things needed.
- XPQuery<Person> – This was probably the moment of the day for me when I saw the way “Linq to XPO” was implemented by DevExpress using the XPQuery generic class. This implementation would prove to be extremely powerful in a number of application scenarios we have faced.
- WCF provider – Although I didn’t managed to ask this during the session I would be keen to see a WCF provider. I know this goes against the grain of ORM but it is often necessary to take an application with a direct data access layer & scale to application servers using WCF. If XPO could offer this it would truly allow a slick upgrade path for applications developed using XPOs powerful ORM which have reached the extent of their scalability because of direct data access.
- How many demos? – The final and most important thing I think to take away from this talk was the sheer volume of demos Gary was able to offer; each one was fully working and addressed a very valid point. 6 demos would’ve been impossible with any of the other ORMs shown, and this was evident when some could not even show a single demo.
- ECO – Scott Price
- UML – This is neat but it kind of takes away from the developer when really the idea of ORMs is to keep the focus on the developer by tidying the data access goo. I certainly struggled to keep up with everything & only managed to take it in after it had been left on the screen for some time.
- OCL – Another TLA which would be required to learn, and it seemed a bit of a “round the houses” way to solve the underlying issue.
- State machines – I had no idea what one of these were before today, and if I’m honest I’m still not 100%.
- Feature set – This implementation of ORM was poles apart from XPO and some of the others and this made it rich to work with, and also somewhat complex & potentially cumbersome.
At the end of the five talks we all had to vote, and I am surprised that ECO scored so highly and XPO so low. My two votes were for XPO & Intact Evolution as these technical demonstrations gave me the most proverbial cud to chew!