Replacing repository pattern with an ORM?

This is a repost of another thread i created. I think my first post was a little rhetorical in nature so it was closed so hopefully i can word my question better.

There seems to be a push by some of the industry heavy weights to recommend using an ORM over the repository pattern and building your on DL Layer. So in your application layer you would be using the ORM directly rather than a repository. An example would be ayende's post here: http://aye开发者_开发问答nde.com/Blog/archive/2009/04/17/repository-is-the-new-singleton.aspx and also reading "Microsoft® .NET: Architecting Applications for the Enterprise" by Dino Espisito where he recommends the same thing.

I am just hesitant, i guess, to tie my DL to an ORM. I haven't used nHibernate and only have light exposure to LINQ2SQL and entity framework v.1. I can only imagine if i would tied a DL layer to LINQ2SQL which has really been deemphasized.

So the real question is do you think its bad practice to use an ORM in place of the repository pattern? There is no question that an ORM could definitely lead to productivity improvements.

I would definitely separate the ORM from my DL. I.e. using interfaces it isn't much work to switch out the ORM you choose.

We have created a project for the repository pattern basics and then use it in all our data layers to ensure consistency and also to aid speed.

I have done this with Active Record and it works very nicely. I can Unit Test without knowing I am using Active Record and also use Integration Tests on the Active Record implementation to make sure that data IO is OK. (Probably a bit of overkill but I like it).

In summary your ORM should help you fulfill your repository pattern not be in place of it.