C# How to set a flexible base for altering controls from assembly later?

Question

Hi @ all :)

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.

Answer 1

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.

Answer 2

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 d**ata 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.