I have at least one child collection on an object based on BusinessBase (CSLA 1.52). When that collection changes, I need to write the history to the project log.
My idea was to use a clone of the original collection and in the internal void Update(Project project) write the history by comparing the collection items. These collections will have no more than 5 items, and the add, update and delete process can be used to write the history. The items are Resource items (people) with a role in the project. We're trying to build history on who does what and what roles are likely to change during a project.
To use the Project Tracker example I'd be doing this in the ProjectResource class. The change itself will be added to the Parent collection of changes:
ProjectResources.Add(history);
It seemed overkill to create events since there is a reference to the parent and the history items are also children.
_E
Thanks, Andrés, but I'm not using AO now and the "comer de coco" factor is just too high for a quick and dirty demo. I did it all in the child. When the child is marked for deletion, update or IsNew, I create an entry and add it to the history collection on the Parent. It's not very sexy, but it'll work for the demo.
Last I tried to use AO, I couldn't get the source to compile. I haven't been able to chase it around and figure it out why. I see that registering the child to the parent is the better way, but I can build a fire with flint & machete, too.
_E
I see the AO site is a little different these days. I dled the current 1.5 Observer.zip and I'll try to use it. That one has a much shorter document to match my attention span. :-]
_E
The observer pattern is used when you want a subject to notify many observers. From what I have read, it seems that you only have one observer (project log). It might be overkill to use the observer in this situation. If you have many observers or think you might have more than one observer down the road, you can use the observer pattern. Otherwise, I would not use it in this situation. I would just use a simple interface to decouple the corresponding objects.
That's what I did, but I believe some of the current project will benefit from an observer. If I can stare at it long enough.
The thing that's stimies me about an Observer pattern is in the disconnected nature of CSLA class design. If each user has instances of objects "checked out", then they save them, how would the Observable item notify all its observers if there's no central point of call (we don't use remoting or a web server, it's all SmartClient)? I don't think they can, so I use a db call to see if the updates table has an newer date than the one the user is using. Can you say cludge?
_E
Copyright (c) Marimer LLC