Consider the case where you want to extract an object out of the database and "send" it to a client. (over the network)

1) You retrieve the object (nhibernate)
2) You serialize the object (then send)
3) Client receives object and deserializes

Is there a way to do this better? I was hoping there was a function in nhibernate to select the "raw" object (ie the bit before nhibernate turns it into an object).

You would then relay this part to the client and it would save the server some processing.

Ideas?

Sounds like you're interested in some sort of Messaging architecture. I don't see how this is an nHibernate question though?

I've got NHibernate working - I know what it does.

It seems a bit of a waste to get the object out of the database and then serialize it. Suppose you are getting an object out of the database - Somewhere in that code is a SELECT statement that NHibernate "translates" into the object you want.

What I'm asking is it there is some way for the server to do the SELECT part and then relay this (i suppose as a dataset?) to a remote client who can do the translation.

This way the server saves 2 jobs:

a) Converting to object from SQL query
b) Serializing object for transmission

Perhaps not a direct NHibernate question/feature but anyone who has to relay a DB object might have come across something that made it more efficient.

Have you looked into .Net remoting? Remoting can use binary transfers so no serialiazation/deserialization occurs. This makes it much easier dealing with proxies and interfaces.

We have a service layer for one of our primary applications that works very much like how you're describing.

We've been slugging through it for about six months in development, and here's what I learned:

1) You don't want to serialize your objects, because full-blown objects are massive, and often have recursive relationships. Clients have Invoices, and an Invoice as a Client, which has Invoices, etc, etc. You need to build Data Transfer Objects (DTO's) that are built for wire transfer. Based on the needs of the consumer, you will often have 1-10 DTOs for a given base class. Some business classes don't need a DTO, like Phone, for example. It only has a few properties (usually), so it's no big deal. But for your complicated stuff, you need to slim them down.

2) Normally the life cycle works like this: (a) Open the session, (b) build a DTO from a persisted business object, (c), serialize the DTO, (d) close the session. When it's time for you to handle an update, you (e) open the session, (f) apply the changes to the persisted object (based on the identifier) from the DTO (g) flush the session.

There's a lot of problems with disconnected serialized data, and if you go the DTO route you can save yourself a lot of headaches. Say you get an Employee sent back to you. Is the sender responsible for sending you a *complete* Employee object? What if the Phone[] collection is null? Does that mean the sender didn't send them, or there really is a null collection?

Sending back DTOs is easy, but taking them in for updates can be more dicey, because for every property you expose on your DTO, you need to handle those on an update. Personally I'd rather have service methods like EmployeePhoneInsert(EmployeeDTO e, Phone p) and EmployeePhoneDelete(EmployeeDTO e, Phone p), and so on, rather than handle that in EmployeeUpdate(EmployeeDTO dto).

For example, you might have a persistent object with 10 fields and have a DTO with only 3 fields? Does that mean you "manually" populate the DTO from the persistent object? eg

Person person = GetPersonFromDatabase( ); //person has 10 fields

PersonDTO dto = new PersonDTO();
dto.Name = person.Name;
dto.Age = person.Age;
dto.Sex = person.Sex;

Do you then to the translation (by hand) on the other side to turn it back into a Person object ?

Do you then to the translation (by hand) on the other side to turn it back into a Person object ?

No. Your PersonDTO object should be designed to contain all of the data elements that your client needs, there is no need to turn it back into a Person object.

Maybe, maybe not.

PersonDTO might have
- PersonID
- FirstName
- LastName

While Person might have all those and a gazillion others, including recursive references like a Supervisor, of type Person.

There's really nothing wrong with having an UpdatePersonDTO(PersonDTO dto) service method which allows you to change the firstname and lastname of a persisted Person.

The alternative is to have an UpdatePerson(Person p) service method, but you can't have that, since you wouldn't be able to serialize the entire object graph of Person.

I manually deal with them. It's a small price to pay, and really not that hard. Open the session, grab the persisted object, apply whatever you got in from the DTO, flush.

The worst thing you can do is start flying schemas around that if someone updates, doesn't get persisted. Or, they request Person, and you don't send them back Supervisor. Does that mean they don't have one, or you just chose not to serialize it?

Every attribute on a schema in an SOA should be valid, across the board. If it means you have to write a bunch of little midget DTOs, so be it.

This implies you are converting back to a Person on the client end ?

Creating DTO's bears similarities to NHibernate when it constructs a proxy object..ie only returning the fields you requested - that would be great if you could use that as your DTO somehow.