Difference between revisions of "System Architecture"

From Heureka Wiki
Jump to navigation Jump to search
Line 96: Line 96:
 
=== Dependency inversion ===
 
=== Dependency inversion ===
  
 +
To reduce dependencies between classes and subsystems, should the subsystems that need a particular service define an interface for that service. For example, the <tt>Forest</tt> subsystem needs biomass to be calculated. To avoid a direct (and circular) dependency from <tt>Forest</tt> to <tt>Biomass</tt>, the <tt>Forest</tt> subsystem declares an interface, <tt>IBiomassService</tt>, and the <tt>Biomass</tt> subsystem implements that interface.
 +
 +
With dependency inversation, a new problem arises, how does an object locate the needed services? There are two common approaches to solving this problem: either Dependency Injection is used, or a Service Locator is used. For Heureka, the latter approach has been used.
 +
 +
The subsystem <tt>Slu.Heureka.BaseLayer.Services</tt> implements a service locator. Key classes in interfaces in that subsystem are:
 +
 +
;IService:Interface that must be implemented by all services
 +
;Service<T>:Generic class for accessing a service
 +
;ServiceAttribute:Attribute that should be set on all services that should be auto loaded
 +
;ServiceBase:Base class for implementing a service
 +
;ServiceManager:The service locator
 +
 +
The <tt>ServiceManager</tt> is a Singleton. It supports auto loading of services (all services marked with the service attribute will be loaded at application startup) as well as explicit loading of services (very useful in unit tests).
 +
 +
The <tt>Services</tt> subsystem was introduced relatively late in the project but has proven to be very flexible and useful. In future development, it is recommended to use it more frequently to reduce dependencies in the system. The recommended approach is that when:
 +
 +
* A class needs to instantiate other classes (except .Net classes), a FactoryService should be implemented
 +
* A class needs to use another subsystem, an interface to that subsystem should be implemented
 +
 +
Static classes and singletons should never be used, with the <tt>ServiceManager</tt> as the single exception to this rule.
  
−
För att minska beroenden mellan olika delsystem bör de delsystem som behöver en viss typ av tjänst definiera ett interface för den tjänsten. Exempelvis deklarerar delsystemet Forest att det behöver tjänsten IBiomassService för att räkna ut biomassa. Delsystemet Biomass implementerar gränssnittet. På så sätt undviks ett direkt beroende mellan delsystemen.
 
−
Klasserna i delsystemet Slu.Heureka.BaseLayer.Services implementerar en enkel service locator.
 
−
Funktionaliteten i Services implementerades relativt sent i projektet men har visat sig vara enkel och flexibel. Vid vidareutveckling kan med fördel fler delsystem göras mer oberoende av varandra med hjälp av denna funktionalitet.
 
 
=== Persisting Data ====
 
=== Persisting Data ====
  

Revision as of 11:35, 20 May 2010

Retrieved from "https://www.heurekaslu.se/w/index.php?title=System_Architecture&oldid=4551"