Difference between revisions of "System Architecture"
Jump to navigation
Jump to search
| Line 117: | Line 117: | ||
Static classes and singletons should never be used, with the <tt>ServiceManager</tt> as the single exception to this rule. | Static classes and singletons should never be used, with the <tt>ServiceManager</tt> as the single exception to this rule. | ||
| − | === Persisting Data === | + | === Persisting Data === |
| + | |||
| + | The system uses both the file system and RDBMS:s (SQL Server) to store data. | ||
| + | |||
| + | * Forest data (stand registers, inventory data, GIS data, treatment units etc) are stored in a RDBMS, the "ForestDb" | ||
| + | * Calculated results and optimization results (plans) are stored in another RDBMS, the "ResultDb" | ||
| + | * Project information and templates are stored in the file system (typically in the user's document folder) | ||
| + | * Application configuration is stored in the file system (typically in the user's application data folder) | ||
| + | |||
| + | Storgate to files are mainly done via serialization. However, a major drawback with serialization is that versioning can be a problem. Also, performance can be an issue. The subsystem <tt>Slu.Heureka.BaseLayer.SerializationManagement</tt> provides helper classes to resolve some of these issues. The classes <tt>SerializationReader</tt> and <tt>SerializationWriter</tt> improves performance drastically. A recommended practice is to always serialize a version number first. By doing this, deserialization of different versions can easily be implemented. A different problem is when a class changes its name or becomes obsolete. A solution for that problem has not been implemented in the Heureka system, but it should be possible to do it using the <tt>[[http://msdn.microsoft.com/en-US/library/system.runtime.serialization.serializationbinder|SerializationBinder]]</tt> class in the .Net framework. | ||
| + | |||
| + | For simple configuration data, the class <tt>ConfigurationStore</tt> should be used. | ||
| + | |||
| + | For control tables, a helper class that serializes control tables has been developed. Thus it is not necessary to implement serialization for control tables. | ||
| + | |||
| + | For interaction with RDBMS the following techniques are used: | ||
| + | ;Data readers: For fast loading of objects, mainly used for forest data | ||
| + | ;Typed data sets: Used when the user is updating data | ||
| + | ;Custom OR-mappning: Used for the result database | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
=== Error Handling === | === Error Handling === | ||
När någon typ av fel upptäcks ska ett exception kastas. Inbyggda exceptions ska användas om de passar (till exempel ArgumentException, ArgumentNullException och InvalidOperationException). I annat fall används egna exceptions som ska ärva från ApplicationException. | När någon typ av fel upptäcks ska ett exception kastas. Inbyggda exceptions ska användas om de passar (till exempel ArgumentException, ArgumentNullException och InvalidOperationException). I annat fall används egna exceptions som ska ärva från ApplicationException. | ||