CODEWITHSUNDEEP
architectureclient-serverdesktop
teo
teo

Reputation: 137

Best approach for multi client desktop application

So the title says it all. Based on the following example which would be the best way to implement it?

Lets have a room reservation desktop software installed on many client machines where each clients can book a room and a centralized database.

So we have client C1 and client C2 and the database where both clients are connected. In the time that a room is booked from C1 i want to show it in the screen of C2 and vice versa and naturally i do not want that a room can be booked on the same time twice.

  1. Should i lock the room in the database when a client starts a reservation und unlock when done (or after a time limit) or just check the database before insert and fail if the room was booked in the meanwhile?

  2. Should i send the request directly to the database or should i implement a server software in front of the database to take the requests?

  3. How to inform the other clients that a room was booked?

    • 3A - pulling the database on the clients side every x seconds?
    • 3B - implementing refresh button for the user (+3A)
    • 3C - pushing the change to all clients through a server software infront of the database?

Point 3C seems to be more complicated since requires the registration of the clients into the server software and making the clients also to small servers for accepting the pushed updates.

I would have chosen: check before insert, send request directly to database (no extra server software) and 3B. So would you recommend the same or do you have any other ideas?

Please mind that i am talking about desktop software and not web applications and not regarding any security issues ;)

Upvotes: 0

Views: 1298

Answers (1)

Marcelo Flores
Marcelo Flores

Reputation: 112

@teo,

My choices would be:

  1. The best apprach is to lock the room. If you perform check before the insertion of the record, you will allow double booking or override some bookings in the case 2 or more clients perform the check at the same time, before ending the reservation and then performing the insertion. Also do not perform the insertion from the client. Create a server to perform this action for you.
  2. Create the server that will response all the requests. Allow clients to open database connections whenever they want is always a bad idea. Your database server may be overloaded very easily, attacked. A server that manages the connections and request is a good idea. It also allows your client to be thiner, and send less data over the network. You can already have a pool of connections available in the server, sparing the creation time. I am only mentioning a few of the tons of advantages of a server.
  3. I would not choose any of your A B C options. As I already mentioned, pulling directly to the database from the client is a bad idea. Implementing a refresh button gives a very bad user experience, and would seem like a software created in the 90´s. And a server pushing always the database to all the connected clients is a waste of resources. Let the clients perform a request to the server when they need something. The server may store some common used data in memory, to avoid query the database when possible.

Summarizing, you can tell that the architecture is clearly a client server one, used a lot of time ago, and this kind of requirements you describe are better treated nowadays with a web app approach, otherwise you would write tons of code to create the server by yourself.

So, unless this is a case of study for college or there are 1000 orcs threatening your life, I would not recommend developing this as a client server, but as a web app.

Cheers,

Marcelo

Upvotes: 1

Related Questions