UI控件库的缺陷

Question

我正在构建一个c# winform应用程序，我继承的框架使用这个库LumiSoft中的UI控件--这些看起来很好，但是很老，而且很有缺陷。以前的开发人员更喜欢他们所允许的更小的尺寸。我最近也免费发现了这些控件：DevExpress --这些控件更新得更新，功能更完整。

因此，我的问题是：

1. 如果存在两个ui控件附加到我的项目的失败呢？
2. 是否值得我花时间用DevExpress取代Lumisoft？
3. 人们对使用UI库(如DevExpress )的一般感觉是什么？

Answer 1

1)这里的缺点是，您最终会分发更多的程序集，因此占用更大的硬盘内存空间，因为您使用的是两组可能在功能上重叠的控件。根据应用程序和目标用户的不同，这可能是问题，也可能不是问题。第二是保持用户界面一致的问题。如果两个库都提供Office 2007外观和感觉它们可能在颜色上不完全匹配，那么您的应用程序看起来可能不一致。

2)只有你才能知道你的项目是否值得花时间。考虑到用来自不同供应商的另一个控件替换控件不太可能是控件类的简单重命名。它们可能有一组不同的属性，因此您需要花时间修改代码，以便它再次编译，然后重新测试，以确保它按预期工作。除非您的客户要求进行更改，否则与添加新功能的时间相比，不太可能值得付出这么大的努力。

3)除非您有一个非常琐碎的应用程序，否则您几乎肯定会使用组件库来节省时间，而不是自己编写所有东西。这就是为什么不碎片整理、DevExpress、ComponentOne和许多其他供应商在组件市场上过得很好的原因。此外，他们的库往往保持最新的外观和感觉，这使您更容易更新自己的应用程序，以模仿相同的外观。

注:还有另一个免费的控制库叫做氪星工具包，但为了公开起见，我要指出的是我自己写的！所以我有偏见地推荐它。

Answer 2

当我决定利用第三方控件时，我所做的就是在我的项目中创建一个自定义控件，它充当第三方控件的一个简单容器。

然后，我创建自己的属性，允许我定义底层控件的设置和定制是如何完成的。为什么要费这么大劲？

因为如果我想从第三方供应商A切换到第三方供应商B，我只需要更改我的自定义控件，所有对供应商A控件的引用现在都消失了，并被供应商B控件所取代。

根据您正在包装的控件的复杂性，这对您来说可能不是一个可行的解决方案。但是，如果您必须找到所有这些旧控件并将它们切换到其他控件，那么现在就提前一点时间可能会为您将来找到更好的控件(甚至选择自己实现)而感到头痛。

祝好运!