How to solve state-stateless in a client-server application?

Question

I\'ve read some books on creating stateless websites, I\'ve read some about stateful client applications, but a lot of complexity comes along when you have to combine both. We h

Answer 1

The reality is that sharing objects between the client and the server is quite complex. Here's what you need to make it happen:

The easy/non-scalable way:

Inherit all of your objects from MarshalByrefObject. If you create Object A on the server, and send it to the client, any client modifications to the object will automatically be forwarded to the server.

While this sounds like the perfect solution, it has two major problems:

1. The client and server are tightly coupled with .NET (bye-bye Web Services)
2. It can be a performance nightmare. All method/property access will be forwarded to the server. If you choose this route, your objects should really be designed for chunky calls, not chatty ones.

The scalable/hard way:

Instead of using MarshalByRefObject, you would use DataContract/Serializable objects. However:

• If you create Object A on the server, and send it to the client, the client will receive a copy of the object (let's call it Object B)
• When you send Object B back to the server, the server will receive a copy of Object B (let's call it Object C)

But you really want the server to treat Object A and Object C as the same. Unfortunately, the CLR cannot do this, so you'll need an Object Merger to sit on both the client and the server.

The Object Merger would contain a dictionary of all objects within the model, and know how to identify two instances as being the same, and merge any values from the receiving end. For instance, if the client already has Object C in memory, and receives an updated copy from the server, it would copy over the values.

Unfortunately, this is also fraught with problems, because you need to ensure that object references are preserved correctly. You can't just blindly update all properties on an object, because the object may have existing references to other objects, which in turn may require their own merging. On top of all this, you would also need to track added/removed objects contained in lists or dictionaries.

I adding n-tier support to my own framework, so I'm going through the same exercise right now (I'm taking the "scalable/hard" route). Fortunately, I have a lot of the supporting infrastructure in-place to assist with identification, merging, etc. If you're starting from scratch, it would be a significant piece of work.

P.S. Add lazy-loading proxies into the mix (I'm using Nhibernate), and it gets even more interesting...

Answer 2

Go read anything by Fowler, particularily his design patterns stuff (especially the assembler pattern and why you need what you are already doing)

Fowler's Patterns Of Enterprise Application Architecture