Question

我不确定是否已经询问过这个问题，但是你应该在UI类中加入多少逻辑？

当我开始编程时，我常常将我的所有代码放在表单上，而每个人都知道这会使测试和维护的对象变得非常痛苦。加班我已经发布了这种做法有多糟糕，并已开始将所有内容分成几类。

有时在重构时我仍然有“我应该把这些东西放在哪里”的感觉，但是因为大多数时候我正在处理的代码是在UI层中，没有单元测试并且会在难以想象的地方打破，我通常最终将它留在UI层。

关于你在UI类中放置了多少逻辑，是否有任何好的规则？我应该寻找哪些模式，以便将来不做这种事情？

Answer 1

处理UI的逻辑。

有时人们会尝试将其放入业务层。例如，一个人可能在他们的BL中：

if (totalAmount < 0)
     color = "RED";
else
     color = "BLACK";

并且在UI中显示使用颜色的totalAmount - 这是完全错误的。它应该是：

if (totalAmount < 0)
     isNegative = true;
else
     isNegative = false;

当isNegative为真时，应该完全由UI层决定应该如何显示totalAmount。

Answer 2

尽可能少...... UI应该只具有与演示相关的逻辑。我个人的偏好现在是拥有UI / View

只是将事件（带有支持数据）提升到PresenterClass，说明发生了什么事。让演示者回应此事件。
具有呈现/显示要呈现的数据的方法
最小量的客户端验证，以帮助用户第一次正确地...（优选以声明方式完成）在无效输入甚至到达演示者之前筛选出无效输入。通过设置min和max属性，确保文本字段值在a-b范围内。

http://martinfowler.com/eaaDev/uiArchs.html描述了UI设计的演变。摘录

当人们谈论自我测试时   代码用户界面迅速提升   他们的头脑是一个问题。很多人   发现测试GUI在某个地方   在艰难与不可能之间。这是   很大程度上是因为用户界面很紧   加入整体UI   环境难以取笑   分开并测试。   但有时会出现这种情况   不可能，你错过重要   互动，有线程   问题，而且测试太慢了   运行

结果一直稳定   以这种方式设计UI的运动   最小化对象中的行为   这很难测试。迈克尔   羽毛清脆地总结了这一点   在简陋的对话框中的方法。   Gerard Meszaros概括了这一点   关于谦卑对象的想法的概念 -   任何难以测试的物体   应该有最小的行为。那样   如果我们无法将它包括在我们的   测试套件我们将机会降至最低   一个未被发现的失败。

Answer 3

我建议UI不应该包含任何类型的业务逻辑。甚至没有验证。它们都应该处于业务逻辑层面。通过这种方式，您可以使BLL独立于UI。您可以轻松地将Windows应用程序转换为Web应用程序或Web服务，反之亦然。您可以使用Csla之类的对象框架来实现此目的。

Answer 4

您正在寻找的模式可能是Model-view-controller，它基本上将DB（模型）与GUI（视图）和逻辑（控制器）分开。这是Jeff Atwood's take。我相信一个人不应该对任何框架，语言或模式狂热 - 虽然重型数值计算可能不应该放在GUI中，但在那里进行一些基本的输入验证和输出格式化是可以的。

Answer 5

附加到控件的输入验证。像电子邮件，年龄，带文本框的日期验证器

Answer 6

詹姆斯是对的。根据经验，您的业务逻辑不应对表示做出任何假设。

如果您计划在各种媒体上显示结果，该怎么办？其中一个可能是黑白打印机。 “RED”不会削减它。

当我创建模型甚至控制器时，我试图说服自己用户界面将是泡泡浴。相信我，这大大减少了我的代码中的HTML数量;）

Answer 7

始终在您正在使用的任何层中设置尽可能少的逻辑。

我的意思是，如果您要向UI层添加代码，请添加该层所需的最少量逻辑，以执行其UI（仅限）操作。

这样做不仅可以很好地分离图层......还可以避免代码膨胀。

Answer 8

我已经为这个问题here写了一个'兼容'的答案。规则是（据我所知）除了UI逻辑之外，UI中不应该有任何逻辑，并且需要管理通用/特定情况的标准程序。

在我们的情况下，我们发现表单的代码是从表单上可用的控件列表中自动生成的。根据控件的类型（bound text, bound boolean, bound number, bound combobox, unbound label, ...），我们会自动生成一组事件过程（例如beforeUpdate和afterUpdate用于文本控件，onClick用于标签等）启动位于表单之外的通用代码。

此代码可以执行常规操作（测试beforeUpdate事件中字段值是否可以更新，命令记录集升序/降序onClick事件等）或基于表单和/或控件名称的特定处理（例如，在afterUpdate事件中进行一些工作，例如计算 totalAmount <的值/ strong>控制 unitPrice 和数量值。

我们的系统现已完全自动化，表单的制作依赖于两个表：Tbl_Form表示应用程序中可用的表单列表，Tbl_Control表示我们表单中可用的控件列表

根据参考答案和SO中的其他帖子，一些用户要求我发展我的想法。由于主题非常复杂，我最终决定打开一个blog来讨论这个UI逻辑。我已经开始讨论UI界面，但可能需要几天时间（......周！），直到我能够专门找到您感兴趣的主题。

你应该在UI类中加入多少逻辑？

8 个答案: