Changes between Version 5 and Version 6 of DependencyInjection

Timestamp:

07/07/12 22:32:22 (12 years ago)

Author:

jesseeichar

Comment:

--

DependencyInjection

@@ -49 +49 @@
 === Advantages: ===
 
-   * Using the Spring dependency injection framework it is simple to replace one implementation of an object with another.  Many objects are already configurable like Resource providers and services but many are not.  For example suppose you wanted to use a subclass of DataManager instead of the standard implementation.  Currently that requires rebuilding Geonetwork.  With spring that is a configuration detail.
-   * The dependency injection also provides a simple plugin system.  Currently Jeeves and sometimes other subsystems have plugins (like services and schedulers) and the code for parsing the xml, instantiating the classes injecting dependencies is all handled in the Geonetwork/Jeeves code.  Spring takes care of this and provides a much more flexible and powerful plugin system than Jeeves.  
-   * In addition dependency injection makes it much easier to perform unit tests, for example a mock DataManager and Database Resource could be injected and a particular component or service could be tested with out requiring the full system to be running.
+   * Using the Spring dependency injection framework it is simple to replace one implementation of an object with another.  Many objects are already configurable like Resource providers and services but many are not.  For example suppose you wanted to use a subclass of !DataManager instead of the standard implementation.  Currently that requires rebuilding Geonetwork.  With spring that is a configuration detail.
+   * The dependency injection also provides a simple plugin system.  Currently Jeeves and sometimes other subsystems have plugins (like services and schedulers) and the code for parsing the xml, instantiating the classes injecting dependencies is all handled in the !Geonetwork/Jeeves code.  Spring takes care of this and provides a much more flexible and powerful plugin system than Jeeves.  
+   * In addition dependency injection makes it much easier to perform unit tests, for example a mock !DataManager and Database Resource could be injected and a particular component or service could be tested with out requiring the full system to be running.
    * Spring already has the concept of "overrides" through inheritance and overriding beans thus making the need for a custom solution nearly obsolete
    * Spring provides some advanced features such as Aspect Oriented Programming.  Some uses for this feature would be to inject an operation before and after any method in the system.  For example one could add an operation each time a metadata is changed without needing to change the code of the core geonetwork at all.  Another example would be to replace keep the implementation of DataManager but override a single method within DataManager.
@@ -63 +63 @@
 === Use cases: ===
 
-   * Currently GetRecords only supports a few output formats, suppose you want to add more output formats.  If the GetRecords, GetCapabilities, etc.. were injected it would be easy to intercept requests going to those services and handle extra formats or (in the case of GetCapabilties) modify the output of the service.
-   * Currently if one want to have object available throughout the system (like DataManager or SearchManager) they have to be added to the Geonet object (or ServiceContext).  However suppose one wants a set of services to be able to communicate together or share an object like a SearchManager then that requires substantial changes to the system.  With Dependency injection it is again just a configuration detail (and of course implementation of the services and the object) and can be added to a release Geonetwork instance.
+   * Currently !GetRecords only supports a few output formats, suppose you want to add more output formats.  If the !GetRecords, !GetCapabilities, etc.. were injected it would be easy to intercept requests going to those services and handle extra formats or (in the case of !GetCapabilties) modify the output of the service.
+   * Currently if one want to have object available throughout the system (like !DataManager or !SearchManager) they have to be added to the Geonet object (or !ServiceContext).  However suppose one wants a set of services to be able to communicate together or share an object like a !SearchManager then that requires substantial changes to the system.  With Dependency injection it is again just a configuration detail (and of course implementation of the services and the object) and can be added to a release Geonetwork instance.
    * Making a statistics module would be much easier since it is very simple to be able to add wrap a method call in a method that will update the statistics.  The wrapping method would have all the input and thus would have access to all the data required for calculating the search, edit, etc… statistics.
-   * Suppose an application has extra restrictions on what users can access a certain metadata.  With dependency injection the getMetadata method on DataManager or XmlSerializer have the appropriate methods wrapped by the dependency injection system to inspect each request and deny those that do not meet the new requirements.
+   * Suppose an application has extra restrictions on what users can access a certain metadata.  With dependency injection the getMetadata method on !DataManager or !XmlSerializer have the appropriate methods wrapped by the dependency injection system to inspect each request and deny those that do not meet the new requirements.
    * Configuration files can have autocomplete if the spring eclipse extensions are installed.
 
@@ -78 +78 @@
 The first iteration will have an architecture that is very similar to the current architecture with some notable changes.  
 
-   * There are still two main layers.  Jeeves and Geonetwork.  The Jeeves module still has the primary concepts like Service, ResourceManager, ServiceManager, etc… and Geonetwork is still the application.
-   * Geonetwork will no longer be responsible for creating classes like the DataManager, SchemaManager, SearchManager etc…  Spring will create all of those classes and wire them together.
+   * There are still two main layers.  Jeeves and Geonetwork.  The Jeeves module still has the primary concepts like Service, !ResourceManager, !ServiceManager, etc… and Geonetwork is still the application.
+   * Geonetwork will no longer be responsible for creating classes like the !DataManager, !SchemaManager, !SearchManager etc…  Spring will create all of those classes and wire them together.
    * Geonetwork will instead be an "Initializer" that is responsible for preparing the non Java dependencies.  For example setting up the database.  Setting certain environment variable/properties that are required by several subsystems.  It will be a Java Bean and therefore any object that requires one of those initialization services before being capable of running will depend on that Bean.
    * All major components will be Java Beans created and wired together by the dependency injection framework.  Spring will ensure that the dependencies are created in the correct order.