我有旧版 win.forms 应用程序，它以非常简单的方式编写，表单在 UI 事件上与 DAL 进行通信。例如，有文本框：登录名/密码、按钮 - “登录”和实现业务逻辑的单击处理程序（要求 DAL 通过 id/密码获取用户，如果不为空 - 则显示下一个屏幕，如果为空 - 显示“重试屏幕”）。
我无法从头开始重写它（在 MVP 或视图/文档模式中），我只想将业务逻辑与处理程序分开：获取与 DAL 通信的现有处理程序代码并将其分组到 UI 处理程序之外的某个位置。
数十个表单由数十个用户控件组成，通常不清楚谁负责业务逻辑。有时它是 UI 控件。但有时它是一个表单，它正在监听自定义 UI 控件事件，然后实现业务逻辑。
如果我分离业务逻辑，谁应该负责调用业务逻辑控制器？表单、用户控件，还是表单和用户控件同时使用？
提前谢谢你！
【问题讨论】：
标签： winforms language-agnostic architecture refactoring
与大多数重构一样，采取小步骤。
首先将代码提取到新方法中。 因此，除了 btnLogin_Click 事件中的所有登录代码，您只需有一个名为 LogUserIn() 的方法或类似的东西。
为部分（或全部）事件处理程序完成此操作后，您可能会开始看到一些常见趋势。也许有一个比较相似的注销。现在你有两个新类的方法。
然后您可以开始在事件处理程序中使用该类。像 UserData.Login(name, pw) 和 UserData.Logout(name)
不要试图一次做所有事情。进行更改，验证它是否有效，再进行更改，验证它是否有效。
请记住，您不必一开始就进行完美的重构，即使是增量更改听起来也会是一个巨大的改进。
【讨论】：
我的主观意见是尽可能多地解耦。将所有业务对象代码粘贴到它自己的库或类中，将与业务对象相关的所有行为放入该类中。然后让您的 UI 代码调用。如果您需要在通信之间等待（例如在巨大的数据库中搜索登录凭据），请暂停 UI，直到它听到来自您的业务对象的响应。这种方法的优点是理论上您可以在将来分发它。让服务器运行后端代码，而 UI 只需发送请求并等待响应。虽然也许我误解了你的问题？
【讨论】：