4

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

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

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

想要重用相关业务逻辑的新代码也将实现此接口，但替换新窗口或可能的预制或参数化答案来回答最初由 UI 组件回答的问题。这样，商务逻辑可以被视为一个真正的库，尽管传递给它的某些方法的接口参数有些尴尬。

这是一个体面的方法吗？我应该如何更好地解决这个问题？我将听从您的集体互联网智慧。

谢谢！

4

4 回答 4

3

我谦虚地建议Model-View-Controller - MVC 很有可能成功解决您的问题。正如您所描述的那样，它将各种逻辑分开。

替代文字

高温高压

于 2010-08-13T20:06:10.643 回答
2

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

我发现这本书在这些情况下非常有用。此外，如果没有先了解面向对象设计的原则，例如SOLID原则，请不要直接进入模式。它们经常指导您选择模式和有关系统演进的决策。

于 2010-08-13T20:11:33.310 回答
1

我会通过清楚地识别实体以及他们可以做或可以对他们做的动作来处理它。然后一一尝试开始为那些从 UI 重构逻辑的人创建独立的业务逻辑对象，使 UI 调用 BL 对象。

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

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

于 2010-08-13T20:11:55.307 回答
0

好的，鉴于您的各种意见，我会采纳 Hoffa 先生的建议并将其扩展。我敢肯定你听说过应该将难题分解成更小的工作单元，直到它们可以被“征服”。

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

来自本书作者的另一个链接。

所以，你一步一步地重构，慢慢地，但肯定地到 MVC 的奶油般的好处。

高温高压

于 2010-08-13T22:48:36.027 回答