Difference between revisions of "How services work"
From RifidiWiki
(New page: ==Why services== The first version of Designer (and also the rest of Rifidi) was littered with a lot of Singletons.<br/> As everybody knows by now: * Singletons are bad. * They are hard t...) |
(→Why services) |
||
| Line 11: | Line 11: | ||
You, as an aspiring rifidi developer, won't need to worry about that.<br/> | You, as an aspiring rifidi developer, won't need to worry about that.<br/> | ||
To make it easier to use the services I wrote a ServiceLocater that does all the work for you.<br/> | To make it easier to use the services I wrote a ServiceLocater that does all the work for you.<br/> | ||
| − | The only thing to remember is to use the @Inject annotation and do the following call.<br/> | + | The only thing to remember is to use the @Inject annotation and do the following call in the constructor.<br/> |
ServiceRegister.getInstance().service(this) | ServiceRegister.getInstance().service(this) | ||
Revision as of 21:48, 3 June 2008
Why services
The first version of Designer (and also the rest of Rifidi) was littered with a lot of Singletons.
As everybody knows by now:
- Singletons are bad.
- They are hard to test.
- Impossible (almost) to mock
So I replaced them with a little service registry where you register a concrete class with an interface this class implements.
Once again I had to discover that somebody else had already had that idea some time ago.
OSGi is an SOA (bright me, reading about OSGi all the time without actually realizing what it means).
So I am using now the OSGi ServiceRegistry to deal with services.
You, as an aspiring rifidi developer, won't need to worry about that.
To make it easier to use the services I wrote a ServiceLocater that does all the work for you.
The only thing to remember is to use the @Inject annotation and do the following call in the constructor.
ServiceRegister.getInstance().service(this)
