相信大家都见过。具有以下逻辑的业务线 UI：“选择 ComboA 时，根据该选择查询值，并填充文本框 B”，或“按下按钮 C 时，禁用文本框 C 和 D”，等等。 . 当您可以对上述逻辑进行多种排列时，情况会变得特别糟糕。
如果有机会重新设计这些可爱的屏幕之一，您会如何处理它？你会在 UI 前面放一个向导吗？你会保留单屏范式但使用其他模式来使 UI 状态的逻辑可维护吗？您将使用什么过程来确定理想情况下如何呈现和实施？
并不是说我认为这对响应很重要，但我目前只看到了这个“机会”，它是一个 ASP.NET 网页，它使用 javascript 来响应用户的选择、禁用控件并进行 ajax 调用以获取更多信息数据。
您可能想要查看的是，这些依赖项中的某些是否并不意味着在看起来相似并提供相同功能的同时，这些元素应该被拆分到多个相似但实际上不同的页面上。有人可能会将这些分组到页面上，因为有足够的相似之处。
如果您可以尝试将问题视为根本没有实现，如果您现在必须实现它，您将如何构建用户界面。如果它完全不同并且现有用户会遇到重大问题，您可能不得不妥协。但正如埃利所说，从用户的角度来看。他们是必须与您的产品一起工作的人。
I would model the state of the whole UI on one object. That object should keep track of the state in which each UI object should be in, including the list of options of a combo box (and which option is selected of course).
That means that having one state object you can correctly re-draw the whole screen and not end up in broken states on the UI. Of course, refreshing all the components each time anything changes is not the way to go, so I would refresh them on callbacks from each of the setters in the state object. This would also allow you to have two UIs over the same state if you ever want that.
从 KISS 原则开始，然后从那里开始工作。不要过度设计解决方案，并尝试从用户的 POV 考虑问题。您对如何构成良好布局的第一印象可能与您应该构建的内容接近，因为良好的 UI 是直观的。
话虽如此，单屏与多屏、JavaScript 或 AJAX 并不重要。如果它看起来不错，易于理解，并且在幕后有很好的注释和清晰的代码编写，那么它就可以工作。它应该是可维护的，因此目标是具有清晰功能的模块化代码块。
我认为最重要的是用户体验，其次是代码的可维护性。在网络上，我尝试尽可能减少往返次数，所以我不确定我是否会采用向导方法，因为这会引导用户浏览多个页面或需要通过 AJAX 替换几乎整个页面（这似乎是错误的） . 我通常与客户合作以获取他们需要的功能，尽管我的目标是功能，而不是实现。我可能会模拟一些示例来向他们展示替代方案，或者只是将它们手绘在白板上给他们一些想法。如果结果是大大改进了用户界面，我不介意在应用程序中做“困难”或“复杂”的事情。当然，我尽可能简单，并且绝对使用良好的做法，即使在 Javascript 中也是如此。