I am thinking on how I could use NHibernate in a remoting scenario (using .NET remoting, WCF, webservices, whatever ...... ), but I can already see some problems which I will likely encounter on my path.

This is how I see the big picture of the application:



Let me explain it in short:
The client application (a rich Windows client for instance) communicates via some kind of technique, be it WCF or the old .NET remoting, with the Service Layer.
This means that the client application calls a (remote) method on the Service Layer to retrieve a Customer for instance. The client can make some changes to that object and later, the client can call the remote 'SaveCustomer' method so that the Service Layer can persist the changes back to the datastore.
In order to do this, the Service Layer uses a Repository that uses NHibernate to retrieve or persist objects.
Note that the Client Application and the Remote service layer use the same Domain Entities. This means that the domain classes need to be [Serializable].

The problem that I will be facing is this:
- Since (N)Hibernate uses its ISession as a UnitOfWork, which keeps track of the objects that have been created, deleted, inserted, the Client Application doesn't know whether it is necessary to perform a remote call to save the entity or not.
(The client application doesn't know anything of some thing called an 'NHibernate Session', and my business object (entity) has no state tracking as well. (In other words: my entity itself doesn't know whether it has been created, changed or deleted).

- The remote method which will save my entity, will use another ISession then the method that has retrieved it. (Remote methods should be stateless, since multiple callers can call the same method. Client x should not know anything of client Y).
The fact that the 'SaveCustomer' method will use another ISession, means that it is possible that NHibernate will perform unnecessary UPDATE statements. This could be problematic if you use an AuditInterceptor, since this Interceptor will update the LastUpdated, Version, etc... columns in the DB, while this was not necessary. In other words: this leads to wrong information in the database.

How could these problems be tackled:
- For the first problem, you could implement some kind of 'state tracking' in your entities, and add a property which tells you whether the entity has modified , etc...

- Implementing state-tracking in your domain entities may also solve the 2nd problem; in your repository you can check whether you've to Update or Save (for new entities) your entity. However, I don't know yet how this will behave in situations where an entity contains a collection of other entities ...


I'd like to know from other people how they have tackled these kind of problems ? Did you implement some kind of state tracking in your business entities ?
Or, did you choose not to expose your business entities to the client application, and use Data Transfer Objects instead ? If so, how did you map these DTO's to your business classes ?

Have you had a look at Billy Mccafferty's article for Nhibernate best practices? He covers several of your points and addresses some of the problems faced.

[url]http://www.codeproject.com/KB/architecture/NHibernateBestPractices.aspx
[/url]

Regards,

Paul[/url]

Thx for your reply :)

I know about this article by Billy McCafferty, but I don't think he touches the problems I outlined here ? This article is not about distributed architectures, but rather about using NHibernate in an ASP.NET app ?

Also very interested in Best Practices in these situations

I never expose my domain objects directly to client services -- in my opinion this builds a direct field-level dependency that basically discourages you from ever changing any fundamentals of your domain representation. Refactoring and redesign should be easy and desirable as conditions change and new functionally is needed, and these things might become downright impossible if your clients are intimately linked to the precise implementation of the way you do things on the server side. So I use DTO objects compulsively which may or may not have very similarly named or typed fields as my domain objects, but still afford me the flexibility to expose domain-specific ideas in an end-result form rather than how I choose to represent those ideas in back-end processes.

I'm not sure I'm understanding your question exactly, though -- why would the client call the save function if it wasn't sure whether or not calling save was necessary? Also, doesn't the presence or absence of an an id generally tell you whether or not something is an update or an insert (assuming a surrogate key)? If that's the case, and the repository is the one that generates the key (or the database), then I would think the repository should know right away whether or not it's a new or existing object. Or is this a question of efficiency where perhaps the client sent in a version of an object that technically had all the same values as the persisted version?

How do you translate your domain objects to your DTO's ? What techniques do you use ? I've read something about NHibernate projections, which should make it easy to do this mapping ?
Can you elaborate a bit more on how you map to and from your DTO's ?


Since the objects don't include any state-tracking (in NHibernate, the ISession does this, and the session is not available at the client), my client doesn't know whether the object has changed or not. (Unless I implement this functionality in my objects so that the client can ask if the object has changed or not).

Not in all cases. Suppose the user has requested an object, and wants to edit it. However, he / she closes the form without changing something to the object.

Indeed. In such cases, the client shouldn't even make the remote call.

DTO is always brought up, but rarely have I see good example on the best practices to implementing them outside of some sort of mapping technique. And even so, how does it handle retrieving by ID's, etc...

ie. if I have a semi large domain object graph (ie. Customer with Addresses, Invoices, Billings, etc...) - mapping that to and from DTO's would worry me. ie. Do I repopulate an entire Customer from a CustomerDTO object sent to the server?

ie.

Customer.Name = CustomerDTO.Name;
...

picture many properties and collections of a customer....

This is also one of my worries regarding DTO's.
As I've stated earlier, I've read something about NHibernate projections, but I need more information about this. I also need to play with it.
If anybody has some fine resources about this topic, plz let me know.