ORM and SOA in the .NET world

Question

From my experience the major ORM frameworks for .NET (NHibernate, LinqToSql, Entity Framework) work best when they keep track of loaded objects. This works fine for simple client-server applications, but when using three- or more tier architecture with Web Services in a Service Oriented Archtitecture, this is not possible. Eventually, by writing a lot of code to do the tracking yourself it could be done, but isn't ORM supposed to simplify DB access?

Is the idea to use ORM in service oriented architecture good at all?

Answer 1

The ORM framework will help you only when directly talking to the database. Even in service oriented architectures, ORMs can only help to reduce the load when programming that final layer. You'll need other techniques -- like WCF -- to handle the service part. I'm not aware of anyone integrating ORM and services yet, but it should be pretty straight forward to annotate the same classes as entities and DataContracts.

Answer 2

LLBLGen Pro has change tracking inside the entities. This means that you can fetch a graph from the database using prefetch paths (so one query per graph node) and serialize it over the wire to the client, change it there, send it back and directly save the graph as all change tracking is inside the entities (and is serialized inside the XML as compact custom elements).

Disclaimer: I'm the lead developer of llblgen pro.

Answer 3

It depends what you mean by 'SOA'. Exposing domain objects in service contracts is rarely good service design - it exposes internal implementation details, there's a greater likelihood of change to a published contract, and versioning becomes very difficult.

If you create custom message documents (eg WCF DataContracts) for your service endpoints, it's relatively easy to use ORM to implement the service. Typically you would reload the domain object from the database and map changed properties (or call a method), then persist the changes.

If your service is mostly CRUD methods, your custom message will effectively be a DTO. You will need to manually manage optimistic concurrency and domain object mapping.

Update: This is an old answer, so I'd like to point out that EF4 also now includes change tracking in entities. I still maintain this is poor service contract design, but if you're just after a distributed application framework, it's probably a good option.

Answer 4

SignumFramework has tracking inside of the entities as well. It also has a full Linq provider, but is ment to work with new databases only (it generates the schema from your c# entities, not the oposite).

Change Tracking: http://www.signumframework.com/ChangeTracking.ashx

Disclaimer: I'm the lead developer of Signum Framework :)

Answer 5

I would humbly suggest that you stop trying to use distributed objects as an architectural pattern. It is just not as effective as either a messaging architecture or a RESTful style.

If you don't like the overhead of transferring data in and out of messages then I would suggest you look at REST. However, not REST in the way ADO.NET Data services does it, that is just distributed objects over HTTP.

REST is more about exposing an ugly(but machine readable) UI on the server and using the client to make it look pretty. In REST there is no knowledge of domain entities on the client so you don't need to send them across the wire.

Answer 6

Take a look at the description of upcoming synchronization and disconnected sets in DataObjects.Net

Answer 7

You can use memcached as a second level cache with NHibernate - is that what you meant by 'Keeping track of' ?