ORM Against a Service-Wrapped Data Source

We are tasked with migrating an existing set of entities (currently POCOs persisted with NHibernate against an MSSQL database) to now persist to some kind of web service (yet to be built, either RESTful or SOAP-based, and that we control).

I like how NHibernate encapsulates the persistence concerns and lets us maintain a logic-rich, persistence-agnostic domain model. Is there any way to make NHibernate talk to a web service at the back end instead of a SQL database directly? In other words, can "service instead of SQL database" be treated as a persistence implementation detail and allow us to continu开发者_如何学Goe to use NHibernate?

Am I asking the right question? :)

NHibernate is an ORM. It maps between objects and relational tables. It does not map between objects and web services. You need to use a different API for persistence oriented web services. You can create a set of interfaces that are implemented by both your NHibernate layer (for the relational database) and the web service layer to make it appear like it's one API.

The question is valid, but unfortunately the answer is no. Ideally you'd design your services to return objects that are relevant to the consumers of your service and you'd use NHibernate to get the data from your database which the service can then use to return to the consumer.

I was actually reading an interesting article about exposing your data through your service layer the other day. http://davybrion.com/blog/2010/05/why-you-shouldnt-expose-your-entities-through-your-services/ It was an interesting perspective on what the role of services play in serving data to your applications.