Delphi 2010 Datasnap - Design Query

5
votes

I am investigating moving a thick client SQL based Delphi application to Multi Tier thin clients, and have been looking at using Datasnap in Delphi 2010. I have worked through the White Paper written by Bob Swart and extended this further.

My main question really is that I want to make the server side efficient in terms of connections and SQL Queries due to multiple queries being run and remaining open at the same time to interrogate data, can anyone point me in a direction for guidance on how to design a real world Datasnap Server application, as the demo's don't go into enough detail.

Thanks Matt

1
delphidelphi-2009delphi-2010datasnap

1 Answers

1
votes

You have to decide in your design:

  • (Mid-Server) Will manage session or client will identify their session each connection (stateful vs stateless)

  • (Mid-Server) How much cached data you desire to have. You can cache just some annoying very stable tables and only querying them when they change (if all modifications is through mid-server, if not, you need something like an arbitrary mark - a GUID, a counter - on the table to match if data changed).

  • (Client/Mid-Server) If your client will always get a full collection of data or just fragments of the collection. (ex.: a product can have an categoryId column, which is a FK to a Category table. You can send both all the time or the client can request only the product data).

  • (Mid-Server/RDBMS)You maybe have to provide some form of custom search. If you have an clue of the most used search conditions, you can provide (if needed) the index covering to do that.

  • (Mid-Server/RDBMS)Don't bring great datasets to mid-server, unless you plan on do some aggresive caching of data and/or have some good use for them. Mid-Server is just another client application to the RDBMS - if both are on the same machine, you can enter in a memory/CPU/IO competition with the RDBMS.

  • (Mid-Server/RDBMS)Execute your business rules on the Mid-Server, is the mantra of many purists out there. For me, equilibrium is key. Let's say the RDBMS have 2000 Stored Procedures (I'm not exagerating, there's real business with such a number of SPs) and your Mid-Server can make an excellent work on 1500 of that 2000 problems solved by SPs, GREAT and do that. But if the last 500 can be a change for worst, let them alone. It can be a bigger hassle than the 1500.. So mix the two, and make those 500 an software project to an other version.

  • (Mid-Server/RDBMS) What I said for Stored Procedures can also be applied to triggers and other any other kind of RDBMS server features that can make your live easier.

  • (Mid-Server/DataSnap)Most of the crude details can be let to dataset provider. But learn to leverage the OnBeforeUpdateRecord event to do custom processing when needed.

  • (Mid-Server/DataSnap)You know you can create a ClientDataset only with modified data by this kind of code below? You cannot imagine how useful it can be... :-)

    Cds_New.Data := Cds_Updated.Delta;