Thursday, 3 January 2008

Messing around with various ORMs

I recently had a quick muck around with a few .NET ORM tools. I took a basic, contrived scenario and tried to implement the same operations using the tools. Here is a quick index:

The examples all go through same steps: the basic configuration required to get going, inserting a couple of records, and then getting some data back out with some simple queries, including traversing a many-to-many relationship.

8 Jan 2008: Quick clarification -- this series is not intended as a review of these tools. It is simply a quick guide to configuring and performing some very basic operations with them. Because all the posts use a (very simple) common scenario, you may be able to draw some basic conclusions about the tools, but in the end you'll probably have to evaluate them for yourself with respect to your own requirements. In which case these posts may help you get started :)


Share/Save/Bookmark

10 comments:

letstalk said...

So in your opinion which one works best?

David said...

Can I cop out and say Mu? :-) The answer is "it depends".

Subsonic is great for quickly getting an ActiveRecord-based DAL up-and-running from a database model.

NHibernate is more complicated, but allows you to use persistence-ignorant entities and supports advanced queries. It also works well when you want to develop a domain model independent of the database model (say, using TDD).

LinqToSql only supports SQL Server (which rules it out for my workplace), and generates entities that are tied to your existing data model. It is also very easy to use.

Entity Framework is about more than ORM -- it is about providing unified access to entities in a number of data sources.

So in short, the one that works the best is the one that best fits your current requirements. :-)

josh said...

You should look at Caslt Project's ActiveRecord. It's easy to get going like SubSonic, and is powered by nhibernate. Almost the best of both worlds.

h32 said...

"LinqToSql only supports SQL Server "
Well this isn't quite true. You can query anything with it. E.g. if you want to use MySQL try DBLinq2007 on google code.

David said...

@josh,
Thanks for the comment. I've been meaning to check out ActiveRecord (and Monorail) forever. I'll try have a look and add it to the series.

@h32,
We just have a difference in terminology I think. When I write "LINQ" I mean the language extensions that can query anything.

When I write "LINQ to SQL" I'm referring to the LINQ provider for SQL, as well as the sqlmetal tool and related designer in VS2008, which I believe is all SQL Server specific. You're quite right though, you can get LINQ providers for a number of data sources.

David said...

@josh,
I've had a look at Castle ActiveRecord as suggested, and added an ActiveRecord version of the sample scenario. If you've got experience with ActiveRecord I'd be grateful if you can point out all the mistakes I've made (particularly the implementation of the many-to-many query). :-)

josh said...

quick turn around on that, and a nice write up. I tend to favor castle activerecord or subsonic depending on the need. that's because nhibernate is a little tricky to get used to.

I haven't used entityframework, and only seen the demos of Linq2Sql. I have this reservation about linq2sql because of the potentially really bad things junior coders could do with it.

Troy said...

One really important advantage of using LINQ to SQL is that by learning the LINQ syntax you’re learning a methodology that can be applied across an ever increasing collection of data repositories. LINQ syntax (such as lambda expressions) can be used to query SharePoint, Amazon and before too long, Oracle.

LINQ is far more than just an object persistence technology. To me, this is one of the most important distinctions in terms of which ORM to invest time in learning.

Anonymous said...

Any chance you will also try out iBatis.Net?

David said...

@anonymous,
Probably won't be adding an iBatis.Net version. My limited understanding of iBatis is that you write the SQL queries for each entity and save them into a mapping file, then iBatis uses those queries to get your entities. I'm more interested in ORM tools that write the SQL for me :)