I think I finally have a grasp on the model-view-controller pattern--no easy feat for me, thanks largely to scouring the Coldbox wiki, which, while spotty in some places, is very rich in others.
But what about lateral communications? Guessing from the way Hibernate works (according to the demos from dev week, as well as the online documentation), models can *have* references to other models, which would then link back to the parent as well. That makes sense from a relational database standpoint.
I am assuming, for the sake of my own sanity, that services should be able to *use* functionality in other services. For our sporting application, races are sometimes just races, but sometimes races have media, and our report is an abbreviated race listing with links to media. So I have a media service which handles the at least 5 different ways to get a list of media, but it uses the race service to add a race and append related media to it, if that makes sense. Because we use stored procedures exclusively, the media service retrieves both the races and associated media in one shot.
In a related note, I have recently tried to implement MVC for an unrelated jquery-driven app that I am writing, and have found the need for a main controller which then talks to separate handlers. In this world, the handlers "handle" specific interactions with the page elements (rendered by the views, of course) and the client, and I have segregated them according to top-level functionality. On the other hand, the models are abstract representations that know nothing about the page elements nor the client.
Hopefully, this sort of lateral communication, particularly across services and controllers, is not compensation for some glaring design flaw that I'm missing. But it works really well, and thinking it through, I cannot see how it violates any core OOP principles--in fact it seems to reinforce them.
