This project is read-only.

NPersist Feature Guide: Persistence to Web Service

Consider the case of a WinForms application that should not be allowed direct access to the database, communicating instead with an application server that in turn is allowed to talk to the database.

Normally this would be an excellent case for a loosely coupled architecture where the client (the WinForms application) and the server make as few assumptions about the internals of each other as possible.

If the application server should be able to support different clients from several different companies, then going for loose coupling - where the only thing the client and the server would have to agree on would be the contract (a.k.a. the WSDL for the Web Service and/or some XSDs specifying the XML in the documents that will be exchanged) – would be almost necessary.

The same applies if the client should be able to connect to multiple different application servers from different companies. And if both these requirements are in effect, so that you have a many-many relationship between clients and servers, the contract based, loose coupled approach applies very, very much indeed.

But what if you know that your team – or at least two teams that are close to each other and communicate well - will be creating both the client and the server and there will be no requirements to support additional clients or servers? Assume that the standard, completely unrealistic expectations on the application to have been developed and put into production some months prior to the point in time when management got the initial idea to write such an application applies.

In such a case it might be tempting to cut a few corners by letting the client and the server assume a thing or two about each other’s internals, saving a bit of time and effort. Who knows – it might even be the correct decision, from a holistic standpoint that takes the business perspective into account.

In such a situation, NPersist has a feature that will allow a client to load from and persist to a Web Service on an application server, which can in turn use NPersist to communicate with the database.

The drawback is that you don’t control the contract between the client and server in this scenario, as well as that it is a very heavy assumption to make that both the client and the server should be running NPersist. However, if those drawbacks seem like nothing compared to the drawback of missing yet another deadline…well, NPersist understands ;-)

In such a setup, the client can be programmed exactly as you would normally code an NPersist application that would be allowed to talk directly to the database. The only difference is that instead of specifying a connection string to the database, you will have to give the URL to the NPersist Web Service on the application server.

When you want to fetch objects by a query, NPersist will send the query to the application server by calling a Web Service that will execute the query and return the resulting objects serialized to xml.

When you want to commit your unit of work, you just call the Commit method on the context object as usual. NPersist on the client will then serialize the changes in the unit of work to an xml document and send it to the application server in a call to a Web Service that will go on to use NPersist on the server to de-serialize the unit of work, perform the changes on the server side objects and commit the unit of work to the database.

This means that the communication profile between your client and the application server will be very non-chatty. All changes are sent to the server in a single call. Queries – including load spans – return all resulting objects in a single call.

Since the programming model in the client is exactly the same regardless of whether you persist directly to the database or to a web service, you will even be able to change between these two options at runtime. A use case would be a client that would be allowed to talk directly to the database while on the Intranet, but as soon as it was out on the public Internet it would have to talk to the Web Service on the application server.

Programming the server is in the standard case just a matter of defining your mapping file and providing the assembly with your domain model. NPersist comes with a Web Service application that is ready to be installed, configured and used directly as it is.

Column level optimistic concurrency

NPersist uses original values for optimistic concurrency, which means that you don’t have to add version columns to the tables in your database to be able to get optimistic concurrency.

It also means that you can get finer grained optimistic concurrency than with version columns. NPersist supports that you specify for each property whether to include it or exclude it from the optimistic concurrency conflict detection (and to include it only when it is modified or whenever it has been loaded).

NPersist also supports that you define different such optimistic concurrency behaviors for delete and update operations for each of your properties. This makes sense because a standard behavior is for objects to include only dirty (modified) properties in the conflict detection when updating an object, but to use all properties when deleting an object (since you rarely update any properties on an object in the same transaction as you delete it). This is also the default behavior for NPersist.

Last edited Feb 23, 2008 at 5:16 AM by matshelander, version 2


No comments yet.