c# - 复杂软件中的所有控件是否都应继承自自写界面

Question

为应该在复杂软件（用 c#/wpf 编写）中使用的大多数控件创建一个界面是个好主意吗？目前我们有一个问题，我们使用来自微软和一些第三方公司的控制。我们的问题是，如果我们想改变一些第三方组件，我们不想改变嚎叫软件，因为我们为我们的客户做了很多定制。

因此，为我们使用的每个控件创建一个抽象类，并且只使用抽象类/接口提供的成员是一个好主意吗？

由于某些原因，这可能是一个糟糕的解决方案，我不明白。

谢谢！

Answer 1

这是一个非常深刻的问题，但我会尽力给你一个答复。

我首先要说的是，将表示逻辑与 UI 控件分开是非常好的。通常，您应该窥探从 MVP 派生的设计模式或使用当前的趋势模式，即 Martin Fowler 发明的所谓“表示模型”。

我强烈建议阅读有关软件设计和最佳实践的所有信息。一个好的开始是在这里阅读所有内容：http ://martinfowler.com/eaaDev/OrganizingPresentations.html

根据我的经验，分离 UI 和表示逻辑的最大收获不是改变 UI 技术，而是让您可以自由地测试非常容易的表示逻辑。在我的整个职业生涯中，我从未切换到另一个 UI 控件提供商。

因此，请记住 TESTABILITY 不会改变 UI 技术。

谈到模式，在 WPF（你说你使用 WPF）中已经使用了一个表示逻辑模式 => 所谓的 MVVM 并不是什么花哨的东西，而是重新命名的旧表示模型。

与您如何看待您的问题有关...您所描述的方法与“模型-视图-演示者”模式更相关，更确切地说，控件中的被动视图子模式被抽象为使用接口的表示逻辑。状态存在于 UI 中，逻辑存在于 Presenter 中。这与状态在演示者中的演示模型模式相反，逻辑也在那里。

我认为你不应该在你的应用程序中混合演示模式，我的建议是：让 MVVM 作为你的基本模式并尝试正确地使用它。这种模式将增强可测试性，我认为您不需要更改您的 UI 技术。但是，即使您要更改它，如果您在 MVVM 模式上正确编码，更改也是可行的。