处理合并的业务和表示代码的最佳方式？

Question

考虑一种假设的情况，即旧的、遗留的表示库多年来一直在维护，并且通过仓促更正和缺乏适当的体系结构监督的过程，逐渐将越来越多的业务逻辑编码到其中。或者，考虑一个业务类或命名空间，它不是由程序集边界与表示分隔开的，因此能够在不强制添加引用的情况下引用System.Windows.Forms之类的内容(这是一个比简单的using子句更令人警醒的操作)。

在这种情况下，这段UI代码使用的业务代码最终会被调用以进行重用，这并不是不可想象的。为了实现这一点，重构两个层的好方法是什么？

我对设计模式比较熟悉--至少在原则上是这样。然而，我没有太多的实践经验，所以我对自己的直觉有点不确定。为此，我已经开始使用策略模式。其思想是确定业务逻辑调用UI组件以向用户提问并收集数据的位置，然后将这些内容封装到一组界面中。该接口上的每个方法都将包含来自原始工作流的面向UI的代码，然后UI类将实现该接口。

想要重用所讨论的业务逻辑的新代码也将实现此接口，但对于最初由UI组件回答的问题，将替换为新窗口或可能的预置或参数化答案。通过这种方式，可以将biz逻辑视为一个真正的库，尽管将一个有点笨拙的接口参数传递给了它的一些方法。

这是一个好的方法吗？我应该怎样做才能做得更好？我将遵从你们的集体互联网智慧。

谢谢!

Answer 1

您似乎采用了一种很好的方法，在这种方法中，您打破了设计中具体元素之间的依赖关系，转而依赖于抽象(接口)。当您打破这样的依赖关系时，您应该立即开始使用单元测试来覆盖您的遗留代码库，并以改进的保证改进设计。

我发现Working Effectively with Legacy Code这本书在这些情况下非常有价值。此外，在未首先了解面向对象设计的原则(如SOLID原则)之前，不要直接进入模式。它们通常会指导您选择模式和有关系统演变的决策。

Answer 2

我谦虚地建议很有可能成功地解决您的问题。它分离了各种逻辑，正如您所描述的那样。

​

​

HTH

Answer 3

我会通过清楚地确定实体以及它们可以或可以对它们执行的操作来处理它。然后，一个接一个地尝试开始为那些将逻辑重构出UI的人创建独立的业务逻辑对象，使UI调用BL对象。

在这一点上，如果我正确理解了您的场景，您将拥有一大堆BL对象，其中的一部分进行win forms调用，win forms调用将需要提升到UI层。

然后，正如JustBoo所说，我认为您将有一个足够独特的情况，可以开始从您的BL和UI中抽象出控制器，并使其在MVC设计中发挥作用。