N-tier architecture

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

Another topic is the server itself:

• for our .net remoting setup, we have an Appdomain for each client, ie. all the dlls are loaded for every connected client
  • this helps with server crashes: if one client crashes, the other clients can continue with work
  • on the other hand, this uses a lot of memory
• for the SOAP/Web service setup of the server, there should be much better scalability
• how much should the server keep track of the state of the client? stateful vs stateless

Glue between Server and Client

different ways of accessing data on the server

• 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, and winforms
• 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

code generation

• 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
• to add new modules (on the level of MFinance, MCommon, etc), edit the NamespaceHierarchy.xml file, and also search for REMOTINGURL_IDENTIFIER_MCOMMON in ICT/Petra/Server/app/Main/ClientManager.cs and ICT/Petra/Server/app/Main/ClientAppDomainConnector.cs and create similar lines of code for the new module
• 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
• Web connector methods are the easiest, they will be added to the interface and the instantiator, and even the winforms: 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

todo

• 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

• Table Maintance: use UIConnector