UI和逻辑之间有什么好的分离？

Question

我正在尝试创建一些n层应用程序，我在分离UI和逻辑时遇到困难，我想知道什么属于UI以及什么属于逻辑。

例如，一个简单的应用程序，允许您登录，然后要求用户填写表单或显示以前的表单列表。我可以想到两种可能的解决方案：

1. 逻辑告诉UI需要登录，然后用户界面要求用户输入用户名和密码并将其发送给逻辑。然后逻辑告诉UI它需要询问用户是否要填写表单或显示以前的表单。然后，UI将此选择发送到逻辑，逻辑告诉UI显示表单或显示列表。 在这里，UI没有状态，而且非常愚蠢，基本上逻辑必须告诉UI要显示什么以及何时显示它。

2. UI显示登录表单，当用户输入用户名/密码时，UI会将这些内容发送给逻辑进行登录。如果登录成功，则UI询问用户要做什么，如果用户想要显示表单显示表单，则如果要显示列表，则UI询问逻辑以显示要显示的项目列表。 在这里，用户界面具有状态，并决定接下来要显示的内容。该逻辑仅用于向UI提供信息以及用于处理UI发送的信息。逻辑没有状态，只是做了UI告诉它做的事情。

我喜欢1，因为UI是无状态的，如果UI崩溃（但不是在不同进程中运行的逻辑），您可以重新启动UI并在崩溃之前继续在同一个地方。它使UI非常轻巧简单。但我想知道哪个更好： 把关于用户在UI或逻辑中做什么的状态。

编辑：

我找到了一个描述逻辑放置位置的document，但主要是逻辑和数据，而不是UI。是否有类似的文档描述逻辑和UI部分？

Answer 1

你正在寻找的可能是MVC（en.wikipedia.org/wiki/MVC），可以说，UI（视图）的组成和显示应该与业务规则分开，最终，这些应该是与数据本身分开。

Answer 2

我正在为我正在进行的当前项目遵循MVP类型的架构，我认为这很棒。我的视图不了解模型，并通过界面与演示者进行通信。从我的演示者内部，我与服务层交谈，而服务层又与我的模型对话。我的观点和我的模型完全不了解彼此。 View会将事件转发到我的演示者，并根据演示者内部的逻辑公开演示者可以更新的属性。