Listener -vs- service layer

Ok, ive been feeling this question for awhile in one of our main applications DataMentor. We have a machii implementation around the application. I am seeing more clearly the reason that we should put our business logic in a service and not a listener. The listeners are part of the application, and our service layer should be application agnostic. I can look back at early design decisions and see bus. logic in the listeners, and even listeners that were playing the role of service or manager. As we build new features into DataMentor, we can follow the best practices of services -vs- listeners and we can continue to re-factor code as we make smaller changes to legacy logic.

Here are a few excerpts from some respected machii architects, Sean Corfield and others.

"If you built a service layer that is independent of the framework that orchestrates actions taken against the model and then you built one or more listeners that mostly just delegate to that service layer, you'll be in good shape."

"Don't think it won't happen to you! I guarantee that you'll find yourself putting a Flex front-end on a legacy Mach II application at some point and you'll wish you too had done a better job of separating your business model from your listeners!"

"Right, a web service front end will also show the same issues. And just to be clear, Flex, Flash and Web Services all rely on the model portion, the CFCs, and not Mach II (or Model-Glue) which is why separating the framework from the model is so important."

See full discussion here.

This is from the machii developers guide on listeners:

Mach II interacts with the Model portion of your application using components that extend MachII.framework.Listener. In a simple application, all of your business logic might be implemented in such listeners but this approach does not scale well with increasing application complexity because, amongst other things, it introduces a tight coupling between the elements of your business logic and the Mach II framework.

You are much better off ensuring there is only a thin layer of coupling between the framework and your application - if necessary, create new components that extend the Mach II listener component, whose sole purpose is to communicate those events to the components within your business model. In other words, try to isolate your business components from the framework components as much as possible: only listener components should know about the framework; only listener components should access Mach II properties; only listener components should announce events. The core business components should know nothing about Mach II and have no dependencies at all on the framework.

In our cfobjective class last month we had a spirited discussion about this. One of the principles i recall was the listeners job being to pass along data to the service layer. The only logic that should be in the listener is logic pertaining to program flow. The listener could announce other events, reference controller properties and set event arguments. When it was done doing these things, it simply handed the event args off to the service. The listener knows nothing about the model layer and the model layer knows nothing about the listener, excepts the names of methods exposed via the API.