处理混合业务和演示代码的最佳方法？

Question

考虑到一个假设的情况，多年来一直保留着旧的遗留表示库，并且通过仓促修正和缺乏适当的架构监督的过程逐渐将越来越多的业务逻辑编码到其中。或者，考虑一个业务类或命名空间，它不与程序集边界的表示分开，因此能够引用类似System.Windows.Forms的东西，而不必强制添加引用（比简单的using子句更加清醒的操作）

在这种情况下，最终将要求重用此UI代码所使用的业务代码并不是不可想象的。为了实现这个目的，将两层分开重构的好方法是什么？

我对设计模式非常熟悉 - 至少原则上是这样。但是，我没有大量的实践经验，所以我有点不确定自己的直觉。我已经开始沿着使用战略模式的道路前进了。我们的想法是识别业务逻辑调用UI组件的位置，以向用户询问问题并收集数据，然后将这些内容封装到一组接口中。该接口上的每个方法都将包含原始工作流中面向UI的代码，然后UI类将实现该接口。

想要重用有问题的业务逻辑的新代码也将实现此接口，但是替换新窗口或者可能替代UI组件最初回答的问题的预制或参数化答案。这样，biz逻辑可以被视为一个真正的库，虽然它的某些方法传递了一些有点笨拙的接口参数。

这是一个不错的方法吗？我该怎么做才能更好？我会尊重你的集体互联网智慧。

谢谢！

Answer 1

我谦卑地建议Model–View–Controller - MVC很有可能成为您问题的成功解决方案。它将各种逻辑分开，就像你描述的那样。

HTH

Answer 2

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

我发现这本书Working Effectively with Legacy Code在这些情况下非常宝贵。此外，如果不首先考虑面向对象设计的原则（例如SOLID原则），请不要直接进入模式。它们通常指导您选择有关系统发展的模式和决策。

Answer 3

我会通过清楚地识别他们可以做或可以对他们做的实体和行动来接近它。然后逐个尝试开始为那些重构逻辑的UI创建独立的业务逻辑对象，使UI调用BL对象。

此时如果我正确理解你的场景，你将手上有一些BL对象，其中一些部分进行了win表单调用，win表单调用需要被提升到UI层。

然后正如JustBoo所说，我认为你将有一个足够明显的情况来开始从你的BL和UI中抽象出控制器，并使它在MVC设计中全部起作用。

Answer 4

好的，鉴于您的各种意见，我会接受Hoffa先生的建议并予以延伸。我相信你已经听说过难以解决的问题应该被分解成更小的工作单位，直到它们被“征服”。

使用该技术，结合Refactoring的方法可以解决您的问题。网上有一本关于它的书和很多信息。你现在有一个链接。该页面包含大量信息链接。

本书author的另一个链接。

所以，你要一步一步地，慢慢地，但肯定地重塑MVC的奶油味。

HTH