Comments on: Choosing an ORM strategy

By: Blake H

Blake H — Tue, 23 Oct 2012 12:50:00 +0000

Stop spreading FUD. I do recommend developers start with an understanding of SQL and then realize that much smarter people have developed solutions that make our jobs less mundane and our code easier to maintain. When you don’t understand how an ORM works, then you are going to have a problem. The solution to that problem isn’t to ignore ORMs.

By: Should we still be using stored procedures? « whygwarren

Should we still be using stored procedures? « whygwarren — Mon, 22 Oct 2012 16:41:54 +0000

[...] against http://lostechies.com/jimmybogard/2012/07/20/choosing-an-orm-strategy/ against I’m still not sure. Share this:TwitterFacebookLike this:LikeBe the first to like [...]

By: Micro-ORMs for .NET Compared – Part 1 « The Public Void

Micro-ORMs for .NET Compared – Part 1 « The Public Void — Mon, 20 Aug 2012 03:20:23 +0000

[...] I have been made aware of a lightweight alternative to full-blown ORMs like NHibernate and Entity Framework. They’re [...]

By: Choosing an ORM strategy | hakre on wordpress

Choosing an ORM strategy | hakre on wordpress — Mon, 30 Jul 2012 07:25:46 +0000

[...] Choosing an ORM strategy (by Jimmy Bogard; 20 Jul 2012) TwitterRedditDiggEmailPrintMoreFacebook This entry was posted in Linked, Uncategorized and tagged Design, Development, Mistake, ORM. Bookmark the permalink. ← wetter.com – Relaunch with symfony2, Assetic, Varnish and Twig [...]

By: Anonymous

Anonymous — Thu, 26 Jul 2012 01:17:00 +0000

I know what you mean. You’re probably stuck with using a complicated wrapper solution that someone else wrote, and it seems like a big black box right? I think you’ll find it’s worth it in the end, especially when you have to write something new and you can tweak the wrapper (or completely rewrite it).

By: Anonymous

Anonymous — Tue, 24 Jul 2012 21:07:00 +0000

Raw SQL all the way. I only use the entity models w/ NHibernate if I’m dealing with one entity.

But, I can still do raw SQL and use NHibernate (or insert other micro-ORM here) for just adhoc DML things.

I even have a process that does bulk insert of persistent NHibernate entities because it’s the fastest way. SQL bulk insert of pre-generated entities flattened out into a datatable because there’s 100s of Ks of records. And since we have a test on it, well, who cares right? Just let it do what it needs to do.

By: Andrei Rinea

Andrei Rinea — Tue, 24 Jul 2012 20:50:00 +0000

Fine article, Jimmy!

I had the opportunity to exchange some tweets about ORMs with you so you might already know my opinion regarding ORMs in general. However I must ask something that is not covered in this article.

How about batch update/delete’s ? How do you handle them? I mean I might need to delete 500,000+ expired rows from the table OFFERS (for example). NHibernate, for example, offers me two alternatives : 500,000+ reads followed by 500,000+ deletes or untyped/stringly-typed HQL.

What’s your recommandation? I do RAW SQL / sprocs for these…

Thank you.

By: Don’t write your own ORM | Jimmy Bogard's Blog

Don’t write your own ORM | Jimmy Bogard's Blog — Tue, 24 Jul 2012 12:49:32 +0000

[...] my last post, I talked about various kinds of patterns of ORMs and how to choose an ORM strategy. From the comments and tweets I got, it seems like some folks still think that their only ORM [...]

By: Demis Bellot

Demis Bellot — Mon, 23 Jul 2012 23:06:00 +0000

Right it’s being used because of performance, 12x faster than Entity Framework:
http://www.servicestack.net/benchmarks/#dapper

By: Demis Bellot

Demis Bellot — Mon, 23 Jul 2012 22:39:00 +0000

The biggest problem with Heavy ORMs is the leaky abstraction. SQL is already a DSL for managing an RDBMS, sticking it behind a heavy ORM requires you to map Relational -> OOP mapping in configuration – which is inferior, more limiting, less verifiable and less explicit than source code.

>> The key is to not tie yourself down to a specific tool or approach.

Although many ORM’s want to own the world, i.e. you have 1 config/dbml model for your entire database. Micro ORMs at least work off connection strings and POCOs, they are easily interchangeable, e.g. at StackOverflow Careers we use https://github.com/ServiceStack/ServiceStack.OrmLite + http://code.google.com/p/dapper-dot-net/ (the 2 fastest ORMs) off the same DB Connection with the same Models.

Since the Micro ORM POCO models are also re-usable, they’re not tainted with RDBMS constraints so we’re free to use them as DataContainers, ViewModels, DTO’s etc when we see fit.

Another problem is the complexity around managing child view objects, in a perfectly normalized database these would all be different tables – In practice you get much better productivity, freedom and versionability storing value objects in schema-less text blobs. We love doing this in NoSQL DBs, but many are still reluctant to do this inside an RDBMS because of decades old teaching.

Here’s an example of the versionability schema-less tex blobs offer: https://github.com/ServiceStack/ServiceStack.Redis/wiki/MigrationsUsingSchemalessNoSql

Because of the productivity wins, OrmLite has first-class support for this where every complex-type property (i.e. non-scalar) is stored in a schema-less text blob, apart from letting you make structural changes without out-of-band DDL changes, it lets you re-use the same POCO in DTOs, Caching/Sessions, NoSQL DBs, Disk/Files, etc:
https://github.com/ServiceStack/ServiceStack.OrmLite#code-first-customer–order-example-with-complex-types-on-poco-as-text-blobs