What is a good separation between UI and logic?

I am trying to create some n-tier application and I am having difficulties separating the UI and the logic and I am wondering what belongs to the UI and what belongs to the logic.

For example a simple application which allows you to login and then asks the user to fill in a form or display a list of previous forms. I can think of two possible solutions:

1. The logic tells the UI it needs to login, the UI then asks the user for the username and password and sends it to the logic. The logic then tells the UI it needs to ask the user if they want to fill in a form or display the previous forms. The UI then sends this choice to the logic and the logic tells the UI to display a form or to display the list. Here the UI has no state and is really dumb, basically the logic has to tell the UI what to show and when to show it.

2. The UI shows a login form and when the user enters the username/password, the UI sends those to the logic to login. If the login was successfull, the UI asks the user what to do, if the user wants to show the form it displays the form, if it wants to display the list, the UI asks the logic for a list of items to display. Here the UI has state and makes decisions about what to show next on its own. The logic is only used for providing information to the UI and for processing information send by the UI. The logic has no state and just does what the UI tells it to do.

I like 1 because the UI is stateless and if the UI crashes (but not the logic which runs in a different process) you can restart the UI and continue in the same place before it crashed. It makes the UI very light weight and simple. But I am wondering which i开发者_运维知识库s better: put the state about what the user is doing in the UI or in the logic.

edit:

I found a document describing where to put logic but it is mainly on logic and data, not the UI. Is there a similar document describing the logic and UI part?

---

What you are looking for is probably MVC (en.wikipedia.org/wiki/MVC), that being said, the composition and the display of an UI (view) should be separated from the business rules and ultimately, these should be separated from the data itself.

---

I'm following an MVP type of architecture for the current projects I'm working on and I think it's great. My views have no knowledge of the model and communicate with the presenter via an interface. From inside my presenter I talk to a service layer that in turn talks to my model. My View and my model are completely ignorant of each other. The View will forward events into my presenter and expose properties that the presenter can update based on logic inside the presenter.