Thin/Fat client

[DKL01]

Hi,

I'm little bit confused about thin and fat clients in VB applications. I have seen few VB applications where business logic and data access logic is written in DLLs.
But the application (.exe) and DLL reside on the same box (for instance NT server). Users will create the icon and map to the exe on the NT server to run the application.
Is this fat client ot thin client ?

Thanks

 

[asjeff]

As a rule of thumb the fat client is where most of the processing takes place and a thin client doesn't consume much memory or processing requirements. Servers are obviously a good example of a fat client because they tend to do all the donkey work (think databases - all the work is usually done on the server (fat client) and the results are returned to the PC that displays them (thin client)).

In your case I would suspect if your application is on the NT server this is the fat client, and your pc your thin client. That is as long as you have specified that the application runs on the server.

Asjeff

 

[jsteph]

The .exe that the user clicks on to run his app always runs on the client (the user machine), whether the .exe exists on the server or not.

A fat client will typpically have business logic--whether in dll's or .exe--which runs on the client.

If the business logic is in a process that runs on a server, such as in stored procedures or an out-of-process dcom .dll that runs on the server, this will be a 'thinner' client, since business logic is done on a different box.

A 'typical' 2-tier client/server app will make all database calls from the client--but, unless you're using ms-access or something like that--the database grunt work is done on the server, but some of your business rules may be processed on the client. This is still considered 'fat', since your forms, user-interface objects such as listboxes and grids, etc, are all rendered and loaded by the client pc.

As a guideline, the ultimate thin client would be a terminal/mainframe. The terminal is basically just the crt and keyboard, and the only thing done on this client is keystrokes and spilling text on the screen. Everything else is done on the mainframe.

A Web app is thin, but fatter than terminal/mainframe because, while most stuff is done on the web server--ie the entire html is written by .asp or whatever--you still have the gui effects rendered by the browser, and maybe some cursory data validation via client-side javascript.

A vb app will be fatter still, but within this range of 'fatness', you can make it thinner by doing more business logic (such as validation, lookups, calculations, etc) in stored procedures or calls to objects which processes on the server.

The better model is a 3-tier app, such as SAP R/3. Here we have a very thin client. This setup has, in addition to the client boxes, a separate box(es) called 'app servers', which process all logic, code, report rendering, sorting, etc--but it makes database calls to still another box--the 'db server'.

So here you have 3 separate pieces of hardware dividing the load: the client box calls for, say a report. The client simply sends the report or process name and some criteria to an app server. The app server runs the code that decides which data to get, and it gets basic data sets from the db server. Complex sql to filter all the data is NOT done by the db server--the app server may typically request more data than is needed by using simpler sql which the db server can process easier--then the app server will do the more complex filtering and sorting and grouping. While this increases some network traffic between the app server and db server, it makes the db servers job simpler, and since the db server and app server are typically in the same building, the pipe will be, say gigabit fiber--while the clients may be in another country over a 56k modem.

This setup, in my opinion, gives tremendous scalability (just add another box to the app-server farm if you add a few dozen more clients), while still getting quick response by the thin client over thin pipes. The db server is tuned to do one thing and one thing only--it gets data and it receives data, that's about it.
It doesn't have to worry about having hundreds of stored procedures or other process running doing data-validation, sorting, grouping, or complex logic and calculations.

I got a little long-winded there but I hope that serves to enlighten.
--Jim