What ORMs are developers using to connect to Azure?

Im interested to find out what techniques developers are using to connect to a Windows Azure instance running in the cloud?

From what i underst开发者_如何学Cand it is very similar to SQL Server with two of the key differences being Multiple Active Recordsets are not supported and idle/long running connections are automatically terminated by azure. For this microsoft suggest incorporating retry logic in your application to detect a closed connection and then attempt to complete the interrupted action. Does any one have example code that they are currently using on this?

To build out the data layer i was looking at various ORMs. Since im going to be accessing azure from windows azure (ie seperate boxes) to me it would seem key that any ORM mapper would need to support asynchronous methods so as not to block any windows azure instances. Any suggestions as to which ORM mapper to use, or comments on what you are currently using

I have successfully used NHibernate with Azure and we are in the process of building a commercial app on top of NHibernate. The only problem that I had was with the connection pools when running locally and connecting to SQL Azure in the cloud - which was fixed when turning connection pooling off.

You may find similar problems with other ORM's... SQL Azure is less patient (for obvious reasons) than most people are used to. Connections timeout quicker, recycle sooner and so on.

Test first!

Here's one specifically designed for Azure:

"Telerik recently announced the availability of Open Access, the first ORM that works seamlessly with SQL Azure relational databases in the Windows Azure cloud."

And a few commenters at the Azure User Group recommend LLBLGen and Entity Framework.

I've been using Entity Framework - runs without any problems, just a different connection string.

What you do have to think about is your connection strategy, and how efficient your queries are. I've got method that's easy to write in EF - I've got a new record that could be duplicated, so I check if it's there, and if not, add it.

EF makes it really easy to do this, as if you're just accessing a local collection. BUT ... if you're paying for your dB access because it's in Azure and not on your local network, hmm, maybe there's a better (aka cheaper) way of doing that

According to Ayende, NHibernate "just works" with SQL Azure.

We have been using NHibernate without any customization on Azure (indeed, it just works), you can check Lokad.Translate as an open source example of such use.