Spring Spike

Owned by Former user (Deleted)
Last updated: Sept 07, 2010Version comment
2 min read

Objective:

  • establish a pattern from Action Class downwards using spring managed classes.
  • use servicefacade/domainservices/daos and best practices. use dtos for web layer.
  • Setup Collaboration using Spring DI (dependency injection) - preferably annotation/autowiring based. Alternatively XML based.
  • move to DAO pattern from FeeBO based persistence.
  • Use Spring transaction manager. manage transaction using AOP, following a naming convention.
  • e.g. - start transaction, whenever a certain service method like org.mifos....ServiceFacade.() is invoked. Follow convention, like get,find,retrieve etc do not require transaction support.
  • testability - no side effects for tests hitting databases. All state changes should be rollbacked. Such that its easy to mock and run tests quickly.
  • do this for all relating classes of Fee (feeAction downwards)

Results:

  • All the above were accomplished.
  • the new codebase uses spring managed transaction using a Hibernate SessionFactory defined in the context. However, it is possible to use entities retrieved from mifos managed HibernateUtil in the same call stack. Other than the master entities, we should consider moving rest of the code to spring managed transaction incrementally.
  • speed of development has increased significantly. Once the infrastructure were setup (spring context def, DAO framework etc), development was quicker.
  • TESTING. This would be the biggest win. Its now possible to have tests hitting the databases yet leaving with a clean state. Time taken for running a integration tests have reduced significantly. No need to create, clean, drop database!

Approach:

  • Essentially followed devised incremental re-architecture strategy as described in Strategies For Architecture Evolution. i.e clean code towards future platform vision. During this spike, if anything was found not amenable to easy refactoring without breaking existing code, the approach was to go ahead and introduce new classes/objects/apis on need basis. This way, we also came up with minimal surface areas, and also only apis that are required.
  • Suggestion has been made that the new fee codebase be moved to a new directory root "org.mifos.platform...." so that we do not mix up the new code with older, and to form a clear separation for future.
  • The coding is done over abstractions, which means the entire implementation can be moved to a separate project, testable on its own, and deployed as a separate jar altogether.