yup, I delivered a few projects with Windsor + CM and the EA in CM is really nice (and slim). For most apps works better than CLR events IMO.
-- Krzysztof Kozmic On Wednesday, 3 July 2013 at 11:30 AM, Rory Plaire wrote: > It sounds to me like your initial reaction was spot on. There are a number of > decent implementations of a generalized eventing/messaging pub/sub to look > at. For example, we use the EventAggregator from Caliburn Micro and have > written our own Castle facility to allow us to adorn events with an attribute > which then wires up a weak listener at component creation time which forwards > the event to the singleton EventAggregator instance as a published message. > It is a very straightforward piece of code to maintain. > > > On Tue, Jul 2, 2013 at 5:57 PM, Tsyoka <[email protected] > (mailto:[email protected])> wrote: > > > Hey Krzysztof. thanks for the quick reply. Appreciated... > > > > "So what exactly are you after?" > > > > > > Hehe... good question. I am still conducting interviews with Domain > > Experts and Stakeholders trying to get a handle on this exact question but, > > based on what I have picked up so far it looks like, for lack of a better > > description, a "bubbled" messaging solution with a high degree of > > composition. Without getting into the ugly domain details right now as I > > would be lying if I had a complete handle on them, I am looking at a number > > of pluggable modules that will be unknown at compile-time but need to > > interact with other modules within the system if installed / available. > > Each module may compose either an entity or, possibly, an entire domain > > context. > > > > My initial reaction to this was to implement the standard Domain Events > > pattern with a Message Bus acting as an orchestrator based on Event / layer > > visibility (ie: persistence events, Application Events, etc) but due to the > > fact that each module will be unknown at compile time I don't want to use a > > static DomainEvents class and was thinking instead of having an IModule<T> > > that contained dictionary of IEventPublishers<T> and IEventHandlers<T>. > > Each event publisher would register with the Message Bus and handle the > > orchestration to handlers based on runtime state. > > > > Anywho... hopefully that made some sort of sense. It's still early phase > > and I am looking at how to handle the wireup and working through some > > spikes to see what might be feasible. The Event Wiring Facility crossed my > > mind but didn't have much experience using it and noticed the "sun setting" > > post so wanted to ask. Right now I also considering IHandlerSelectors or > > Interceptors to see what might be the cleanest implementation to handle the > > event wireup on object creation or state change. As I mentioned, its still > > early phase in the modeling process but want to get a high level > > understanding of how the infrastructure / plumbing code will need to > > function before making promises on domain features. > > > > If you have any ideas I would love to hear them... This is definitely a > > more interesting scenario than the standard three-calls setup I usually use > > Windsor for and might help someone else dealing with a similar scenario. > > > > Thanks again, > > > > Tsyoka > > > > -- > > You received this message because you are subscribed to the Google Groups > > "Castle Project Users" group. > > To unsubscribe from this group and stop receiving emails from it, send an > > email to [email protected] > > (mailto:castle-project-users%[email protected]). > > To post to this group, send email to [email protected] > > (mailto:[email protected]). > > Visit this group at http://groups.google.com/group/castle-project-users. > > For more options, visit https://groups.google.com/groups/opt_out. > > > > > > -- > You received this message because you are subscribed to the Google Groups > "Castle Project Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected] > (mailto:[email protected]). > To post to this group, send email to [email protected] > (mailto:[email protected]). > Visit this group at http://groups.google.com/group/castle-project-users. > For more options, visit https://groups.google.com/groups/opt_out. > > -- You received this message because you are subscribed to the Google Groups "Castle Project Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/castle-project-users. For more options, visit https://groups.google.com/groups/opt_out.
