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 have a Flex application that needs to persist data to a database via .NET services. Things to keep in mind are: - Concurrency (optimistic/pessimistic) - Performance: Flex needs to load in lots of data so lazy-loading is often necessary. - Do you use Dto's to tranfer data between server and client?

I'll tell you the history of our product. We've used SubSonic from the beginning as a o/r mapper. SubSonic objects are converted to dto's written by us and these dto's are transferred to the client. Clientside the dto's are converted to the domain model. If clientside a domain model object needs to be saved, it is converted back to a dto and send to the server. Server side the dto is converted to a subsonic object and saved to the database.

Now, some time ago, we needed the domain model on the .NET server side... so now we have like three models on the server side, the subsonic model, the dto model and the domain model. The dto model is more simple and resembles the database more, the domain model has much more logic. It gets complex... We now have to synchronize the AS3 domain model code with the C# domain model code. If we could do it again (of get time to refactor) I think we wouldn't use the dto's anymore, but transfer the domain model between client and server. Question is if this is realistic. Dto's are simple objects so easy to transfer. Domain model objects can be very complex.

Are there books on how to create an architecture for these kind of applications? Books writte by someone with lots of experience? Do you have experience with this?

Answer 1

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

Answer 2

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...