ORM to abstract a traditional database plus a WCF service.

Question

Suppose one is using Microsoft's Entity Framework as an ORM to abstract/work with a database. Next comes a requirement which causes the application to have the need to work with a WCF service and a traditional database, simultaneously.

To my knowledge no ORM tool exists that can abstract a WCF service in the same manner as Entity Framework.

Is there anything on the market that can help with this task? The goal is to abstract the WCF and the traditional database in such a way that to the domain programmer it appears as if they are working with one database. They should not have to care or worry that underneath entities are being dissected and persisted in multiple places (WCF or database)

--- EDIT ---

Note that the WCF service is 3rd party that we do not have any control over. But at the same time we need to talk to a totally different database as well, which happens to be a traditional MS Sql database.

Answer 1

Have a look at the new WCF Data Services.

When .net 4 is available you will be able to use EF with Plain Old CLR Objects (POCO).

http://msdn.microsoft.com/en-us/data/bb931106.aspx

Answer 2

Well, I think you're getting things a bit mixed up here:

A ORM is needed to bridge the object-vs.-relational data "gap" - you need to map between rows and columns in your relational database, and your objects with properties in your OO world. That's the ORM's job, and that's what these tools are good at (more or less).

However: a WCF service is just a way of shuttling around objects - I don't really see any gap or discrepancy to "map" over here. Yes, there's a number of issues you need to deal with and you need to think about - but basically, WCF services will send you back (typically) an object or a collection of objects or something like that.

So really, if you have an ORM doing the mapping between your relational database and your object model, you already have objects - WCF is merely a way of making those available to the outside world etc. - but there's no real mapping between two disparate worlds here.

If you need to map your EF entities to some lighter-weight data transformation objects (DTO) to be sent across the WCF service, you might want to have a look at AutoMapper to easily map between two different objects. But again: you're not fundamentally bridging any technology gaps here - just mapping around between two sets of objects.