考虑到一个假设的情况,即过去几年一直存在一个旧的,遗留的演示库,并且通过快速更正和缺乏适当的架构监督,逐渐将更多的业务逻辑编入其中。或者,考虑一个业务类或命名空间,它不是通过汇编边界与演示分离,因此能够引用诸如System.Windows.Forms之类的东西,而不必强制添加引用(比简单的使用子句更加清醒的操作) 。处理混合业务和表示代码的最佳方法?
在这样的情况下,它不是不可想象的,通过这个UI代码中使用的业务代码最终会在重复使用被调用。为了实现这个目的,重构这两层的好方法是什么?
我对设计模式非常熟悉 - 至少在原则上反正。但是,我没有一整套实践经验,所以我对自己的直觉有点不确定。我已经开始沿着使用策略模式的道路。这个想法是确定业务逻辑调用UI组件的位置,以向用户提出问题并收集数据,然后将这些数据封装到一组接口中。该接口上的每个方法都将包含来自原始工作流的面向UI的代码,然后UI类将实现该接口。
想要重用有问题的业务逻辑也将实现这个接口,但是替代无论是新窗口或可能的pre-fab或参数回答最初由UI组件回答这些问题的新代码。这样,biz逻辑可以被视为一个真正的库,虽然有些尴尬的接口参数传递给它的一些方法。
这是一个体面的方法吗?我应该如何更好地处理这个问题?我会顺从你的集体互联网智慧。
谢谢!
谢谢你让我今天学习一个新词。我仍然不确定我是否知道混合的含义,但是我将立即开始使用它! – 2010-08-13 20:02:27
是您的基本问题“我如何从UI中存在的一堆业务逻辑创建业务逻辑层?” ? – 2010-08-13 20:04:59
我对融合的印象是把两件事合并为一,通常带有错误/否定的基调。很高兴你喜欢我的文辞!但是,是的,基本问题并不是真正的“如何制作三层”,而是从实际的角度来看,“我该如何解决这个问题”。 – bwerks 2010-08-13 20:49:16