+972 52-548-6969
Disconnected Mode Change Tracking
There is some interesting discussion going on right now about dealing with change tracking in disconnected mode. The whole discussion started when Andres complained that this making writing diconnected updates much harder than it should. You can check the links to see the whole discussion, what I am interested at is Udi's second reply, in which he suggest doing something like this:
void IBus.Send(params IMessage[] messages);
With the client code looking like this:
myBus.Send(addOrderLineMsg, delOrderLineMsg);
I am not sure that I agree with the choice of names (specifically, IMessage to me in an infrastructure level idea, IOrderMessage is something that would have a meaningful business sense), but I really like the idea. Then I started to think about it. Sending the server a bunch of changes, so it could execute them in a single transaction, thus reducing the chattiness of the conversation, I am pretty sure that I heard it before. Indeed, it is my favoriate pattern, Unit Of Work, expanded to include a multi layered, service based architecture.
I really like this approach.
Comments
IMessage IS an infrastructure interface, as is IBus, and IMessageHandler. The exist to codify distributed communications.
The specific messages sent are defined in a different package.
Does that clear it up a bit?
Check out http://udidahan.weblogs.us/2006/06/02/can-indigo-be-my-bus/ for some more information.
I think that we may be talking about two different levels here.
IBus & IMessage are infrastructure, as such, I really don't care about them when thinking about the service interface.
Unless you are talking about true IMessage, in which the messages are not conforming to any schema (ws-duck), which I don't think you do.
I am thinking about the interface that the service exposes as a way to pass Command messages, so I would have AddLineToOrderCommandMessage, for instance, and it would implement IOrderCommandMessage, and the service would accept only message that conform to valid IOrderCommandMessage implementations.
I just read your post about it, and I think that I understand it better now.
The idea of a bus that dispatch messages by their schema is interesting, but I am not sure if I like it.
Can you explain to reasons for using:
myBus.Send(addLineToOrder);
vs.
orderService.Send(addLineToOrder);
Unit of Work:
Would this work in NHibernate if there was such a thing as a 'disconnected' ISession ?
Because the ISession is handling the state changes, not the objects themselves - right?
Good post, I've been struggling with this issue on how to properly use NHibernate with my Web Services.
Define disconnected.
You can certainly work with a session that is not connected to a database, and you can even serialize and de-serialize a session, if you really feel like it.
an object is retrieved from a webservice, changes are made on the client (winform), the object is sent back to the webservice where an update is called.
No need to do anything special.
Make sure that you would define a <version> property, and head your merry way.
when the object is received from the WS, create a session and attach the object to the session ( session.Lock(obj, LockMode.None); ) and then save.
NH will take care of concurrency.
Excellent.
You know, I have read as much as I can on this and never realized this was available.
I'm rather new to NHibernate (if you can't tell by now... lol). Is there any simple barebones sample of what this would look like?
I've seen several questions on this on NHibernate boards and AR boards and have yet to see this response.
Thanks again Ayende (as always!)
The idea of having a generic bus object that dispatches message objects to their appropriate message...
The idea of having a generic bus object that dispatches message objects to their appropriate message handler objects seems to have struck a chord with Ayende (aka Oren). It is definitely one way of doing the Unit-of-Work Pattern that also...
Comment preview