MVP中渲染逻辑和业务逻辑之间的准则是什么？

Question

我正在研究一个GWT应用程序，并被告知for循环构成“业务逻辑”，不应该在MVP视图的实现类中。所以作为一种习惯，我从不在我的viewImplementation类中使用for循环，而是将循环放在Presenter（Activity）中，并在viewImplementation类中调用一个方法来完成循环的每个迭代任务。

我知道演示者不包含小部件并且具有业务逻辑。相反，viewImplementation类是您拥有小部件并保留渲染逻辑的地方，但是将for循环分类为业务逻辑的指南是否过于严格？

是否有一些关于使用GWT将MVP的业务逻辑归类为业务逻辑的指南？

Answer 1

我不同意“for循环构成业务逻辑”的陈述。它是一种语法结构而非业务逻辑。如果他正在发表该声明，则遵循（IMO）您应该避免“如果声明”。这将是多么实用和/或可行！？

业务逻辑是您放置在循环结构中的内容，而不是构造本身。这一切都取决于你在循环中放置的逻辑，这将是决定因素。

修改

我能想到的一个例子演示了如何在View中找到for循环，而根据“for循环”规则，它应该只放在模型中。

想象一下，您想制作一个工具栏，上面有字母A-Z，用户可以点击该工具栏来过滤搜索结果。

视图负责向用户显示内容。出于这个原因，我认为使用以下for循环来生成View中的工具栏是最合适的方法。

伪代码

Let TB <- Toolbar control
for letter = 65 - 90 (A - Z)
begin
      let item <- Toolbar Item
      set item's text to letter
      add item to TB
end

这似乎揭穿了循环始终构成业务逻辑的声明，因此必须放在模型中。