C# 如何设置灵活的基础以便稍后从程序集更改控件？
我对 C# 还是个新手，我正在开发一个项目，我们还使用 WPF 和 WPF DataGrid 工具包（请参阅 CodePlex），该工具尚未发布到框架中。 由于项目的性质，100% 确定我们稍后会更改装配的一些控制。 我的同事决定在我们项目的命名空间内重新定义数据网格中的每个控件，并删除程序集命名空间的特定控件。 所以不要使用： clr 命名空间:Microsoft.Windows.Controls.Primitives;程序集=WPFToolkit clr 命名空间:Microsoft.Windows.Controls;程序集=WPFToolkit 我们将使用我们自己的 xxx.Controls 和 xxx.Controls.Primitives 命名空间。 这样，改变继承控件就变得非常容易。
不知何故，我对这个解决方案有一种不好感觉，但我仍然缺乏经验，无法判断这种方法是否合法，或者是否有另一个好的解决方案可以满足我们的要求（稍后更改控件而无需更改多个文件中的太多代码）。
如果您对这种方法表达您的意见，那就太好了。
I'm still new with C#, and I'm working on a project where we also use WPF, and the WPF DataGrid Toolkit (See at CodePlex), which hasn't yet been released into the framework. Due to the nature of the project, it's 100% sure we will be altering some controls of the assembly later.
My co-workers have decided to redefine every control from the datagrid within a namespace of our project, and ihnerit the specific control of the assembly namespace.
So instead of using:
clr-namespace:Microsoft.Windows.Controls.Primitives;assembly=WPFToolkit
clr-namespace:Microsoft.Windows.Controls;assembly=WPFToolkit
We'll be using our own xxx.Controls and xxx.Controls.Primitives Namespaces.
This way, it would be pretty easy to alter the ihnerited controls.
Somehow, I got a bad feeling about this solution, but I'm still inexperienced and cannot tell if such an approach is legitimate or not, or if there is another good solution to our requirements (altering the controls later without changing too much code in multiple files).
It would be nice if you express your opinion to this approach.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
你所说的改变是什么样的改变？ 在您知道实际需要更改什么之前先从每个类中派生似乎是浪费时间。
当您确实需要更改某些内容时，此时创建派生类并修复任何引用应该不会太难 - 这可能仅适用于某些实例而不是全部。 是的，这可能意味着签入涉及相当多的文件 - 但如果您使用合理的源代码控制系统，这将是一个原子更改，并且它发生变化的原因将是显而易见的。
使用您当前的方法，不会立即出现“这些是我们必须更改的控件” - 如果您以“及时”的方式进行操作，您只需查看派生控件即可知道你实际上必须创造。
What kind of alterations are you talking about? It seems like a waste of time to pre-emptively derive from each of the classes before you know what you'll actually need to change.
When you do need to change something, it shouldn't be too hard to create the derived class at that point, and fix up any references - which may only be for some instances rather than all of them. Yes, it may mean check-ins involving quite a few files - but if you're using a sensible source control system it will be an atomic change, and it will be obvious why it's changing.
With your current approach, there's no immediate "these are the controls we've had to change" - if you do it in a "just-in-time" manner, you'll be able to tell just by looking at what derived controls you've actually had to create.
我同意你的看法。 改变，或者更好地说，改变，可以是任何类型的。 行为等等，改变要及时。
不幸的是，这不是我的决定。 一些固执的人在工作:)
但令我感兴趣的是，是否存在一种完全不同的方法来实现整个想法？
假设我有一个 DataGrid，项目不断发展，现在我必须对 dataGrid 行的验证行为进行一些重大更改。
这也适用于许多控件。
我们项目的问题是，我们有一种复杂的数据访问层，它不仅提供数据，而且实际上控制数据。 这意味着如果不包含数据访问层提供的某些逻辑，则不会读取、修改、删除或附加数据。
例如，数据网格不会直接删除行，而是我们覆盖删除行为并要求数据访问层删除它。 通过绑定，目前效果非常好。
这种场景未来还会应用到很多其他的事情上，比如CRUD操作、验证等等。
I agree with you. The alterations, or better said, the changes, can be of any kind. Behavior and etc. And the changes should be make just in time.
Unfortunately, that is not my decision. Some stubborns are at work :)
But what is interesting me is if a complete different approach to the whole idea exists?
Say, I've got a DataGrid, the project evolves, and now, I've got to do some drastic changes in the validation behavior of dataGrid rows.
This could also apply to a lot of controls.
The problem with our project is, we have a kind of complex data access layer, which not only provides data, but also actually controls it. This means data isn't read,modified, deleted or appended without including some logic provided by the data access layer.
For an example, the datagrid doesn't directly delete rows, but instead, we overwrite the delete behaviour and aks the data access layer to delete it. With binding, this works pretty good for now.
This kind of scenario will apply to a lot of other things in the future, regarding CRUD operations, validation and etc.