处理合并的业务和演示代码的最佳方法？
考虑一种假设的情况，即一个旧的、遗留的演示库多年来一直被维护，并且通过仓促的更正过程和缺乏适当的体系结构监督逐渐将越来越多的业务逻辑编码到其中。或者，考虑一个未通过程序集边界与表示分离的业务类或命名空间，因此能够引用 System.Windows.Forms 之类的内容，而无需被迫添加引用（这是比简单的 using 子句更清醒的操作） 。
在这样的情况下，这个UI代码所使用的业务代码最终会被调用重用并不是不可想象的。重构这两层以实现这一点的好方法是什么？
我对设计模式比较熟悉——至少在原则上是这样。然而，我没有大量的实践经验，所以我有点不确定自己的直觉。我已经开始使用策略模式来实现这一点。这个想法是确定业务逻辑调用 UI 组件以向用户询问问题并收集数据的位置，然后将它们封装到一组接口中。该接口上的每个方法都将包含原始工作流程中面向 UI 的代码，然后 UI 类将实现该接口。
想要重用相关业务逻辑的新代码也将实现此接口，但替换为新窗口或可能是 UI 组件最初回答的问题的预制或参数化答案。这样，业务逻辑就可以被视为一个真正的库，尽管传递给它的某些方法的接口参数有些尴尬。
这是一个不错的方法吗？我应该如何更好地解决这个问题？我会尊重你们集体的互联网智慧。
谢谢！
Considering a hypothetical situation where an old, legacy presentation library has been maintained over the years, and has gradually had more and more business logic coded into it through a process of hasty corrections and lack of proper architectural oversight. Alternatively, consider a business class or namespace that is not separated from presentation by assembly boundaries, and was thus capable of referencing something like System.Windows.Forms without being forced to add a reference (a much more sobering action than a simple using clause).
In situations like this, it's not unimaginable that the business code used by this UI code will eventually be called upon for reuse. What is a good way to refactor the two layers apart to allow for this?
I'm loosely familiar with design patterns--at least in principle anyway. However, I don't have a whole ton of practical experience so I'm somewhat unsure of my intuitions. I've started along the path of using the Strategy pattern for this. The idea is to identify the places where the business logic calls up to UI components to ask the user a question and gather data, and then to encapsulate those into a set of interfaces. Each method on that interface will contain the UI-oriented code from the original workflow, and the UI class will then implement that interface.
The new code that wants to reuse the business logic in question will also implement this interface, but substitute either new windows or possibly pre-fab or parameterized answers to the questions originally answered by the UI components. This way, the biz logic can be treated as a real library, albeit with a somewhat awkward interface parameter passed to some of its methods.
Is this a decent approach? How better should I go about this? I will defer to your collective internet wisdom.
Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我谦虚地建议 模型–视图–控制器 - MVC 很有可能成功解决您的问题。正如您所描述的那样，它分离了各种逻辑。
HTH
I humbly suggest Model–View–Controller - MVC has a high probability as a successful solution to your problem. It separates various logic, much as you describe.
HTH
您似乎采取了一种很好的方法，即打破设计中具体元素之间的依赖关系，转而依赖抽象（接口）。当您打破这样的依赖关系时，您应该立即开始使用单元测试来覆盖您的遗留代码库，并以改进的保证来改进设计。
我找到了这本书有效地处理遗留代码< /a> 在这些情况下是无价的。另外，在没有首先了解面向对象设计原理的情况下，不要直接跳入这些模式，例如 SOLID原则。它们通常指导您选择有关系统演化的模式和决策。
You seem to be taking a good approach, in which you break dependencies between concrete elements in your design to instead depend on abstractions (interfaces). When you break dependencies like this, you should immediately start using unit tests to cover your legacy code base and to evolve the design with improved assurance.
I've found the book Working Effectively with Legacy Code to be invaluable in these situations. Also, don't jump right into the patterns without first looking at the principles of object oriented design, like the SOLID principles. They often guide your choice of patterns and decisions about the evolution of the system.
我会通过清楚地识别实体以及它们可以执行或可以对它们执行的操作来处理它。然后一一尝试开始为那些从 UI 重构逻辑的人创建独立的业务逻辑对象，使 UI 调用 BL 对象。
此时，如果我正确理解您的场景，您将拥有一手 BL 对象，其中某些部分进行 win 表单调用，win 表单调用需要提升到 UI 层。
然后，正如 JustBoo 所说，我认为您将拥有足够独特的情况来开始从 BL 和 UI 中抽象出控制器，并使其在 MVC 设计中全部发挥作用。
I would approach it by clearly identifying the entities and the actions they can do or can be done to them. Then one by one try to start creating independent business logic objects for those refactoring the logic out of the UI, making the UI call to the BL objects.
At that point if I understand your scenario correctly you would have a hand full of BL objects, some portion of which made win forms calls, the win forms calls would need to be promoted out into the UI layer.
Then as JustBoo says, I think you'll have a distinct enough situation to start abstracting out controllers from your BL and UI and make it all function in an MVC design.
好的，考虑到您的各种意见，我会采纳霍法先生的建议并加以扩展。我相信您听说过应该将难题分解为更小的工作单元，直到可以“解决”它们。
使用该技术，再加上重构的方法可以解决您的问题问题。有本书和网上有很多关于它的信息。您现在有一个链接。该页面有大量信息链接。
来自该书作者的另一个链接。
因此，您可以缓慢但坚定地一步一步地重构 MVC 的优点。
华泰
Okay, given your various comments, I would take Mr. Hoffa's advice and extend it. I'm sure you've heard hard problems should be broken down into ever smaller units of work until they can be "conquered."
Using that technique, coupled with the methodologies of Refactoring could solve your problems. There is a book and lots of information on the web about it. You now have a link. That page has a ton of links to information.
One more link from the author of the book.
So, you refactor, slowly but surely to the creamy goodness of MVC, step-by-step.
HTH