我有遗留的win.forms应用程序，用非常简单的方法编写，其中表单与UI事件上的DAL进行通信。例如，有文本框：登录/密码，按钮 - “登录”和实现业务逻辑的点击处理程序（如果为空，则要求DAL通过ID /密码获取用户，如果不为空 - 则显示下一屏幕 - 显示“重试屏幕”）。我只是想将业务逻辑从处理程序中分离出来：获取与DAL通信的现有处理程序代码，并将其分组到UI处理程序之外的某个位置。使遗留下来的直接win.forms应用程序代码更加清晰
几十个表单由几十个用户控件组成，并且通常不清楚谁负责业务逻辑。有时候是UI控制。但有时候这是一种表单，他正在监听自定义UI控件事件，然后实现业务逻辑。
如果我分开业务逻辑，谁应该负责调用业务逻辑控制器？表单，用户控件或表单和用户控件同时？
预先感谢您！
我的主观意见是尽可能多地分离。将所有业务对象代码粘贴到它自己的库或类中，将与您的业务对象相关的所有行为都放入该类中。然后允许您的UI代码调用。如果您需要在通信之间等待（例如搜索大型数据库以获取登录凭据），请停止UI，直至听到业务对象的响应。这种方法的优点是，你理论上可以在将来分发它。让服务器运行后端代码和UI简单地发送请求并等待响应。虽然也许我误解了你的问题？
与大多数重构一样，采取小步骤。
首先将代码提取到新的方法。 因此，而不是btnLogin_Click事件中的所有登录代码，您只需要一个名为LogUserIn（）的方法或其他方法。
一旦您为某些（或全部）事件处理程序完成此操作，您可能会看到一些常见趋势。也许有一个注销比较相似。现在你有两种方法来创建新课程。
然后，您可以开始在您的事件处理程序中使用该类。像UserData.Login（name，pw）和UserData.Logout（名称）
不要试图一次做所有事情。进行更改，验证它是否有效，进行其他更改，验证它是否有效。请记住，您不必将完美的重构直接出门，即使是渐进式的变化听起来像是一个巨大的改进。
谢谢，那是关于我目前要做的事情。但我要求进一步一步。什么时候我会把所有的业务逻辑放到不同的UI类中，而UI处理程序应该负责调用它？有时它是用户控件：btnLogin_Click调用UserData.Login（）。但可能是应该是一种形式？登录控件具有OnLogin事件窗体监听，并且它是一个调用UserData.Login（）的窗体。我想要一些统一的方法。或者可以混合使用代码？ – 2010-06-17 14:15:27
可以采用混合方法。但是，我可能会去处理调用业务代码的事件处理程序。原因在于，如果您想要更改GUI，则新的GUI可以调用该代码，但可能很难让您的业务代码监听不同的事件。除非我不清楚你在问什么。 – taylonr 2010-06-17 16:54:06
想象一下，我有“登录”用户控制2个文本框和按钮“登录我”。谁负责调用UserData.Login？至少有2个地方。我可以处理btnLogMeIn_Click事件，并在那里调用UserData.Logic。将自定义事件添加到登录控件的另一个选项：OnLoginEvent并在窗体中处理它。现在窗体负责调用UserData.Login。你个人是什么？ – 2010-06-17 17:40:45
好吧，谢谢，但它看起来像我现在要做的事情：把业务对象代码放在一个地方（停止UI处理程序和业务逻辑组合）。所以这个代码可以通过方法从UI访问。我想知道谁会称这些新方法：形式或控制。想象一下，我有用户控制“登录”：2个文本框+ 1个按钮。在按钮点击时应该“登录”调用业务逻辑方法还是应该“登录”有“OnLogin”事件并委托业务逻辑调用来形成？现在的代码有混合的方法：有时控件，但有时形式包含业务逻辑 – 2010-06-17 14:08:01
啊我明白你的意思是形式与控件现在。我会说与最不共同的分母。如果您计划重复使用具有不同控件的表单类，将这些调用方法放置在表单本身上并使控件触发事件可能更安全。 回到您的登录示例..如果您想要某种形式的验证，所以我们假设凭证是错误的，您需要显示一条消息..在我看来，如果表单处理此行为会更好，因为控件应该在大多数情况下彼此不知道。 – 2010-06-17 14:14:26
但是，如果您要遵循Windows标准，将所有行为放在表单中是一个不错的选择，因为我认为这与afx消息映射的行为类似。 – 2010-06-17 14:15:03