While reading the Google's Percolator paper I have noticed that Percolator supports observers - the capability to run specific logic
when data in the particular column has changed. This reminded me of triggers. Usual database triggers. As a common knowledge - something bad to use.
I will not list here the disadvantages of the triggers - they are well known. Lets look at the positive
side of them.
I realized that the triggers are almost perfect decoupling facility. It is a declarative way to set
the logic to be invoked when some row (object) in my data base (data model) has changed.
I am not aware of OO languages / frameworks which do allow such perfect flexibility. I can assume that aspect oriented
programming will allow something similar, although I doubt that it will be the match.
If you have heard of the way to achieve the same or similar capability without usage of the triggers - I would be happy to know.
Subscribe to:
Post Comments (Atom)
IMHO triggers are never justified as legitimate at design stage. Only as a hack and quick-fix for the lazy. The better alternative for decoupling is to build an API facade of stored procedures there do all the coding.
ReplyDeleteRegarding oo languages and frameworks: besides hardcore aspect-oriented frameworks that really have marginal use for the same reasons db triggers have marginal use, one can leverage popular frameworks such as Spring IoC and on wiring config stage put the interceptors. Same about Google guice and jboss aop. And of course: old good vanilla java dynamic proxies.