N-tier architecture: Difference between revisions

From OpenPetra Wiki
Jump to navigation Jump to search
No edit summary
Line 1: Line 1:
= Client/Server Architecture =
= Client/Server Architecture =
== Glue between Server and Client ==
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
* the code for interfaces and instantiators is generated
* first edit file csharp/ICT/Petra/Definitions/NamespaceHierarchy.xml (TODO?: change to yml for easier readability)
* first edit file csharp/ICT/Petra/Definitions/NamespaceHierarchy.xml (TODO?: change to yml for easier readability)
Line 8: Line 19:
* 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
* 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


=== different ways of accessing data on the server ===
== different ways of accessing data on the server ==
* UIConnectors: only used for screens; keep an object on the server for each screen
* UIConnectors: only used for screens; keep an object on the server for each screen
* LogicConnectors: keeps an object on the server side; needed for progress bar; eg. Report Calculation
* LogicConnectors: keeps an object on the server side; needed for progress bar; eg. Report Calculation

Revision as of 11:41, 21 July 2009

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

different ways of accessing data on the server

  • UIConnectors: only used for screens; keep an object on the server for each screen
  • 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
  • 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
  • Table Maintance: use UIConnector