Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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?

share|improve this question

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.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.