So it has been a while since I really wrote a domain model from scratch. I need to write a domain model that keeps track of models. So, a meta model for models...basically think the class/properties/relationship hierarchies you see in IDEs.
Naturally, there will be plenty of referential integrity to keep track of inside the model when things change, move, get renamed etc. So, an event-driven model sounds logical, where other parts of the model listen for events from other model components and update their state when changes elsewhere occur.
Ok, so it has been a while since I wrote change listeners and event mechanisms...has anything changed in the last 5 years or so? Any updated design patterns? New approaches? I did some searches and it seems all new writing on this topic stops around 2002 or so. So what does this mean...no one writes event driven models anymore?
Are there any handly open source frameworks out there that makes this a snap...oh, and I don't think Spring will be an option in this case.
Joined: Aug 08, 2006
Event driven models still make as much sense as ever to use. They are still in use all over the place and new designs should never hesitate to use them whenever they make sense.
As far as "new" design patterns, if you couldn't find any new material on event driven design patterns, I would say that the "classic" ones you were using a few years ago are still valid.
Joined: Sep 11, 2006
Thanks so much John,
One thing I did look into was using aspects to intercept changes and fire the events. That might be a somewhat newer appoach? Anyone used aspects for this?
In fact, i would be interested to hear what experiences people have had with aspects overall.
Joined: Aug 08, 2006
I would still think you should use traditional un-aspected code where possible. I don't think aspects bring that much to the table that a nice set of Event classes and Interfaces can't accomplish in a more OO and well-understood manner, and without needing AspectJ or some other new tool. I don't think events are truly "cross cutting" enough to require Aspects.