I am not talking about simple UI logic like clicking a button directs you to another page, but where one action may result in several different of behavior depending on current application state, and may also trigger response in other parts of the application. Currently my view publishes all UI event so the response can be delegated to other parts. The problem is which other part? In order to avoid writing 'fat' controllers that hold arbitrary amount of domain logic, I thought it might be nice to have a non-persistent object that models UI behavior, but am not sure if this makes sense or if I am just pushing the problem around and being object-happy?
- Anybody can ask a question
- Anybody can answer
- The best answers are voted up and rise to the top
Well, in my point of view, whatever logic there is for presentation should go into View Helpers. Controllers should only orchestrate the connection between Views and Models by interpreting user actions.
Models should be bare-bone, minimal. I only use them to validate stuff. And than do all the business related things in your classes related to your business logic. Let the Models be "Request Models" as defined by Robert C. Martin.
Uncle Bob's approach to this problem is great and it really helps. Try it. It may be the answer to all your dilemmas.