业务逻辑在大型winforms应用程序中入侵UI

Question

我看到这个主题现在不止一次出现。我希望那些目前处于类似情况或过去的人可以提供一些有见地的建议。如果你也分享过去的经历可能会有用。

因此，这些相当大的Windows窗体应用程序已经开发了多年。虽然开发团队已经尝试将业务逻辑与UI分离，但它并没有完全发生，并且代码中有许多区域，其中业务逻辑硬连接到UI。实际上，在很多地方都可以看到以前尝试采用MVP架构的残余。还有单元测试，但代码覆盖率相对较低。然而，有一些热点 - 每个人都知道的领域变得越来越复杂，他们必然需要。

很多时候，只有当测试人员抓住他们的火炬灯并且真正开始寻找不幸太晚，昂贵且有风险的错误时，才能找到可能早先发现的错误。工程师，测试人员和PM--都意识到需要做些什么。

完全解决这种情况或改善情况最实际的方法是什么？由于这将是一项长期任务，衡量目标进展的最佳方法是什么？如何以客观的术语来定义目标？

Answer 1

您需要重新架构业务层，然后将UI连接回此重新架构的层 在完成此操作后，您将保留现有UI和硬连线业务逻辑，并一次将其切换为一个新表单。

这样可以让您在效果很小的情况下添加所需的所有单元测试和自动测试工具。您还可以确保您的组件正在执行他们正确执行的操作。

基本上，短期内投资回报率有限，但中长期（实际上只是长期）潜在的巨大收益。

Answer 2

产品的盈利程度如何？ 团队有多大？

这些问题将成为解决方案的起点。团队越有利可图，越大，您就能越快地将代码重构为更新的表单。

但是对于大型项目，代码更改通常存在很大风险。必须有多年来没有看过的“正常工作”的领域。在这些领域获取漏洞将是一个巨大的挑战。需要一段时间才能让你的齿轮转动甚至调试这些区域。

我的目的是详细研究代码。如果您确定知道它很冷，请向代码库中知识渊博的其他人进行演示。这将指出您认为但不知道的下一批代码。当代码开始进入你的脑海时，你脑海中会出现一个更清晰，更清晰的图片。然后你准备好为第一步制定计划。让它变得合理，不要太过分。

最重要的是，学习并享受乐趣。只要你有正确的态度，重新开展一个大项目就会很有趣。

Answer 3

“入侵用户界面的商业逻辑”......我喜欢选择这个词。

• 首先，通过单元测试获得代码覆盖率。
• 之后，请查看Martin Fowler的Refactoring书。
• 应用一系列Extract Class重构以形成域图层。在每一个之后，重新运行您的单元测试以确保您有绿色条。
• 一旦您对新代码感到满意，请删除旧代码。
• 最后，您需要Introduce Controller。

当然，一个棘手的部分是对UI进行单元测试。您可能必须在UI本身中首先Extract Method才能对在那里浮动的逻辑位进行单元测试，然后按照上述步骤进行操作。

Answer 4

听起来你面前有很多挑战！

从最广泛的角度来说，我认为你必须首先与你的团队合作，明确定义你认为可接受的和不可接受的东西。

根据我的经验，某些程度的业务逻辑（例如验证）必须在UI中（尽管它也应该在业务层中实施）。

一旦你明确了什么是可接受的和什么不可接受的，那么列出项目中的违规行为应该是一个相对机械的（虽然令人生畏）任务。

这将使您清楚地了解问题的严重程度 - 如果您打算以任何可衡量的方式解决问题，那么这是唯一可以合理开始的地方。

Answer 5

听起来像是我的典型应用。