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

我不确定是否已经提出过这个问题,但是你应该在UI类中添加多少逻辑？

当我开始编程时,我常常把我的所有代码放在表单上,​​就像每个人都知道的那样,这对于测试和维护的屁股来说是一个绝对的痛苦.加班我已经发布了这种做法有多糟糕,并开始将所有内容都分成几类.

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

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

只是处理UI的逻辑.

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

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

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

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

当isNegative为true时,应该完全取决于UI层应该如何显示totalAmount.

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

只是将事件(带有支持数据)提升到PresenterClass,说明发生了什么.让演示者回应此事件.

有渲染/显示数据的方法

最少量的客户端验证,以帮助用户在第一次正确完成时...(最好以声明方式完成)在无效输入甚至到达演示者之前对其进行筛选,例如确保文本字段值在ab范围内设置最小和最大属性.

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

当人们谈论自我测试代码时,用户界面会迅速抬头问题.许多人发现测试GUI在艰难和不可能之间.这主要是因为UI与整个UI环境紧密耦合,难以分开和测试.但有时候这是不可能的,你会错过重要的交互,有线程问题,而且测试运行速度太慢.

因此,设计UI的方式一直在稳步运行,以最大限度地减少难以测试的对象的行为.Michael Feathers在The Humble Dialog Box中清晰地总结了这种方法.杰拉德·梅萨罗斯(Gerard Meszaros)将这一概念概括为一个简陋对象的概念 - 任何难以测试的对象都应该具有最小的行为.这样,如果我们无法将其包含在我们的测试套件中,我们可以将未检测到的故障的可能性降至最低.