我的GUI类(winforms)中有一堆逻辑示例。我将重构它,以便gui中没有逻辑,并且一个单独的类拥有所有逻辑。
这种模式是什么?假设我有一个名为AddAddressForm的表单类,你会称之为保存逻辑的关联文件? AddAddressMediator(不太适合该模式),如果我在做WPF,我会称之为ViewModel(但我不是)。
答案 0 :(得分:2)
听起来像没有模型部分的模型 - 视图 - 控制器。
答案 1 :(得分:2)
我不认为它叫什么。我曾尝试过使用Windows Forms做过那种事情,但遗憾的是它并没有真正起作用:
对于每个表单,我有另一个名为MyFormLogic
的类,它应该包含我对表单的所有逻辑,表单本身只包含大量用于操作表单的方法和事件(类似于{ {1}}事件和AddButtonClicked
集合属性)
当时这似乎是一个绝妙的主意(Yay easy单元测试!),但实际发生的是AllItems
类变得和以前一样大而且杂乱,现在我有很多额外的在我的实际表单类中公开额外方法事件的无意义代码。 (同时创建表单实例也很痛苦)
我建议您尽可能多地将逻辑重构为许多较小的类来完成一件事,而不是一个额外的类来处理所有形式的逻辑(很难解释我的意思,没有一些实施例)
答案 2 :(得分:2)
根据给出的示例,您的对象似乎共享某种常见数据。
然后查看Flyweight Pattern。
答案 3 :(得分:2)
我相信它被称为Model-View-Presenter模式。虽然它通常在asp.net中使用,但它也应该应用于WinForm。
http://msdn.microsoft.com/en-us/magazine/cc188690.aspx
Martin Fowler将原始的MVP模式分为2种模式,Supervising Controller和Passive View,但我仍然喜欢它的原始名称MVP。
答案 4 :(得分:1)
它取决于逻辑类型,比如你有Conditonal Logic并且你从中创建了不同的对象,所以在新类中分离它将指向Factory Method。
2-如果你的班级中有复杂的算法并且你将它分成另一个类,你最有可能使用策略模式。
许多其他组合也是可能的。
答案 5 :(得分:1)
它是模型 - 视图 - 控制器(MVC)。在您的示例中,Model是Address,View是对话框,Controller只是将对话框中的事件调解到Address对象。
注意:您可以在非常简单的情况下省略Controller,但如果您想要自动单元测试,则不;分离(通过接口)将获得回报。
答案 6 :(得分:1)
我相信这被称为Humble View。
有关详情及其不同之处,请参阅Humble View section of the GUI Architectures page on martinfowler.com。
答案 7 :(得分:1)
您所描述的仍然是Model-View-ViewModel模式,它不是特定于WPF的。核心原则是ViewModel包含状态和逻辑,View不断与ViewModel同步。使用WPF绑定很容易,但它们不是先决条件;任何有状态的UI都可以使用MVVM。在视图方面,模式的Forms风格可能非常冗长。
答案 8 :(得分:0)
通过将视图和功能分解为不同的文件,听起来像是基本的关注点分离。不确定它是否真的属于任何形式的说法,但它确实提醒我网页形式与视图和代码背后的一点点。