Client/Server Architecture

There are several options how to design a client/server architecture.

It depends on what environment you are using (bandwidth, datalink speed, etc) and on your requirements (supported operating systems etc).
On the other hand you want to try to keep the logic in one place (the server), so that several types of clients can connect the one server.
Also access to the database should go all through the server, so that you don't need to create a database user for each of your users, and access permissions are handled by the server.

Several types of clients:

Standalone: this is for single user systems; they don't need to know that a server is started in the background.
Fat client, Rich client: this is in our case a Winforms application, that connects to a server. The client can handle the logic, but perhaps we want to keep it still simple on the client. Updates/Patches to the client need to be run semi automatically.
Slim Client: this could be a web client; it requires no installation effort.
- Rich Internet applications (RIAs) look like desktop applications, but run in the web browser

Glue between Server and Client

the code for interfaces and instantiators is generated
first edit file csharp/ICT/Petra/Definitions/NamespaceHierarchy.xml (TODO?: change to yml for easier readability)
then run nant generateGlue for the first time
then you can create a UIConnector .cs file; the constructor will be added to the Instantiator and to the interface the next time you run nant generateGlue
- a method that should not be added to the interface, should either be private, or have comment [NO-REMOTING] (with 3 slashes)
you can also add a method to the instantiator, and put its codeblock in a ManualCode region; next time you generateGlue, the method will be added to the interface

UIConnectors: only used for screens; keep an object on the server for each screen
- advantage: server knows about the client; minimum data transfer, diffs are enough.
LogicConnectors: keeps an object on the server side; needed for progress bar; eg. Report Calculation
ServerLookup: used for static methods; no object is held on the server; eg. Verify Partner in ExperimentingClient; UserDefaults uses ServerLookups internally
- WebConnector: very similar to ServerLookup; easy generation of interface and instantiator: just make sure the namespace exists in the NamespaceHierarchy.xml, and then add your method to the Webconnector class; run nant generateGlue, it will create the interface and instantiator for you, and even nant generateWinforms will add functions to edit windows etc
Cacheable: also static methods; they are not called by the developer, but by the Cachemanager on the server and the client side, when you are accessing a cached table

Todo: something special about UIConnectors; extra things are generated for UIConnectors
the others are implemented manually at the moment

TODO: progress bar; need different threads; keep the connection; prevent the object from being garbage collected
- need extra object on server for progress and cancel option (eg FReportingGenerator.AsyncExecProgress)
- keep the main object (eg. FReportingGenerator) alive by registering it