> -----Original Message----- > From: Robert Taylor [mailto:[EMAIL PROTECTED]] > > My point of contention is with the view or > view helpers containing the logic which actually > interacts with the business layer therefore > circumventing the controller. That is, I wanted > to make the point > that the controller is responsible for interacting with the > business layer > and subsequentially making the model info (DTOs) accessible > to the view.
For what it's worth I've found that adding the concept of a transformer to the holy trinity of Model/View/Controller helps clear things up a bit. Now you can say that an event comes in (an HTTP request, let's say), a controller reacts to it (a Struts action) and figures out what model to poke at, that model updates itself and fires an event, a controller reacts to it (most likely the same Struts action serving double duty), and tells a transformer to transform relevant bits of the recently updated model into *another* model, which will be view-specific. Then the view accesses *that* model directly. The extra concept I think makes it very clear that the controller is simply a fairly dumb router, whereas the smarts of moving a model from layer A to layer B are encapsulated in something very purpose-specific. If you make this distinction--either implicitly or in code--then if you're like me you'll start to notice that a lot of code that you write lives in the transformer realm. And it's usually this area that changes the most. Hopefully this made some sense and helps. It's bad when I'm this inarticulate and it's not even Friday. Cheers, Laird -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
